Cream of the Crop 20

home *** CD-ROM | disk | FTP | other *** search

/ Cream of the Crop 20 / Cream of the Crop 20 (Terry Blount) (1996).iso / database / mbpro19e.zip / MBPRO.DAT / MBPRO.TXT < prev next >

Wrap

Text File | 1996-05-22 | 230KB | 7,334 lines

ModemBase PRO REFERENCE MANUAL RELEASE 1.9x 5/22/96 *** IMPORTANT *** You must read the quick start (QUIKSTRT.TXT) before continuing here. (also available as a bulletin on our bbs) Please note this manual was originally written for release 1.7x of ModemBase Pro. At that time the new MBMASTER was not yet created. Please read MBMASTER.DOC or use the context sensitive help built into MBMASTER. All references in this manual to COMPOSER and MBMANAGE have been replaced in functionality by MBMASTER. COMPOSER and MBMANAGER are now no longer needed and MBMASTER should be used. A new manual is currently being re-written and will be available in the commercial release of 2.0 This file has been specially formatted for printing by copying to your printer via the "copy mbpro.txt lpt1" dos command. ModemBase Pro commercial release includes a printed bound manual. ***************** SECTION 1 - MBACCESS The purpose of this manual is to provide a reference and instruction guide for ModemBase Pro On-Line Database Management (DBMS) Software. MAILING ADDRESS : ----------------- NetConnX 27475 Ynez Rd Suite 302 Temecula, CA 92591 PHONE NUMBERS : --------------- Sales : (909)699-2216 (M-F 9am-5pm PST) Office : (909)699-2216 (M-F 9am-5pm PST) BBS : (909)699-2212 (24 Hours, 7 Days/Week) FAX : (909)699-2216 (24 Hours, 7 Days/Week) Tech : (909)699-2216 (Voice technical support - M-F 9am-5pm PST) V-Mail : (909)279-3053 (Voice mail system with information/messaging) E-Mail : tgetty@netconnx.com ___________________________________ ModemBase PRO TERMS AND CONDITIONS ModemBase Pro, MBPRO, ModemBase Access, MBACCESS, MODEM BASE Master, MBMASTER, are all trademarks of NetConnX and are copyrighted material covered by law from copyright infringement. All other Trademarks belong to their respective companies and are subject to protection under any applicable laws. ModemBase Pro and products categorized as Members of the ``MODEMBASE Pro Family are released as ''Commercial Software ModemBase Pro Test Drive is a EVAL Full working version '' of the Commercial release of ModemBase Pro DBMS and ONLY ModemBase Pro Test Drive may be distributed freely. If you own a Commercial Version of the ModemBase Pro software, you are REQUIRED BY LAW to NOT distribute this software. To do so is in direct violation of copyright law and may result in prosecution to the full extent of the law. Beta Test versions are to be used only by authorized NetConnX ModemBase Pro Beta Testers and will expire after 30 days of usage. Test Drive Versions may easily be upgraded to a full commercial release version via an auto update registration process. Consult with NetConnX at (909)699-2216 (Voice) or (909)699-2212 (BBS) if you have any questions regarding your license agreement. DISCLAIMER : This product is distributed and sold ``as is'' and without warranty, except for the media on which this program is distributed. NetConnX will not be liable for any damages or loss of income either direct or indirect from the use of any of the ModemBase Pro family of products. Use of this product implies that you agree to these terms and conditions and that you also agree and abide by the terms and conditions as stated specifically in your license agreement as outlined in the LICENSE.DOC file distributed with ModemBase Pro. LICENSE.DOC is distributed separately to allow for customized agreements if needed. Consult with your License Agreement LICENSE.DOC for further information specific to each individual ModemBase Pro product. i __________________ ACKNOWLEDGEMENTS : Jim Pierce of NetConnX is the lead programmer responsible for ModemBase Pro development. Troy Getty manages all ModemBase Pro Sales and Marketing efforts along with design and conceptual work. Special thanks to the NetConnX staff that helps with the ModemBase Pro development and support effort : Joe Martin, Osiel Rodriguez, Danielle Wright, and Christy Gisel. The ModemBase Pro Alpha and Beta testers are instrumental in providing us with bug reports and many great ideas that have greatly contributed to ModemBase Pro's success. They have endured so that you won't have to. DEDICATION : We dedicate this project to our customers who without them none of this would be possible. ii Contents Acknowledgements: ii DEDICATION: ii Introduction 1 What is ModemBase Pro? 1 Manual Layout 2 What ModemBase Pro is Not. 3 Chapter 1 5 ModemBase Pro Concept 5 Chapter 2 9 Database Primer 9 Chapter 3 17 Getting Started - The Light Bulb! 17 Operational Requirements 17 Quick Start Installation 19 MBACCESS - THE DOOR 27 Chapter 4 31 Security Access 31 iii Chapter 5 37 Overview of Databases and Files 37 Chapter 6 43 Configuration Database 43 Chapter 7 59 Linkage Database 59 Chapter 8 73 Default User Profile 73 Chapter 9 75 The On-Line Interface 75 Chapter 10 87 Advanced Concepts 87 iv Introduction What is ModemBase Pro? ModemBase Professional_ is a complete On-line Database Management System (DBMS). The product name is meant to imply using a modem to connect remotely to an on-line database of information. Although ModemBase Pro_ works perfectly on a local PC and a remote system is not required, ModemBase Pro is specifically designed to work with existing on-line systems or as a stand-alone system and provide an easy-to-use on- line interface to callers accessing database information. Database files are in commonly used industry standard dBase_ III file format. This means that ModemBase Pro can use existing or new databases created or used by literally thousands of other popular database applications that also support dBase_ III file formats, hereafter referred to as xBase. Additionally, ModemBase Pro_ is often used to supplement other database management software packages providing the on-line interface. ModemBase Pro_ allows System Operators (Sysops) to design complete information systems that can be accessed remotely via modem. Not only is it designed to be easy-to-use for the caller, but it is also designed to be easy-to-use and setup for the Sysop, requiring no special programming skills. 1 Manual Layout This manual is divided into two different sections. The first explains in detail ModemBase Access, hereafter referred to as MBACCESS. The second explains ModemBase Manage in detail, hereafter referred to as MBMANAGE. Each section is then broken down into chapters and then presented in a logical manner to bring the reader into focus with the operation of ModemBase Pro and its many capabilities. 2 What ModemBase Pro is Not. ModemBase Pro was designed to be easy-to-use and we have intentionally created a system for non-programmers. The savvy database programmer may at first find ModemBase Pro a bit awkward, because of our unique approach for simplicity. Instead of functions which work on data in an obtrusive nature, we offer easy-to-use link types (which you will learn more about later) to instruct ModemBase Pro how you want your data to be processed. Many years of combined effort from our developers and customers have gone into designing an intuitive easy-to-use on-line interface for callers. You won't find any mysterious boolean search functions, but we do offer powerful telescopic search mechanisms for finding and transferring needed data efficiently and quickly. This and many other similar attention to details has made ModemBase Pro the defacto standard for on-line database management. The entire interface, with the exception of the browse screen and the command items, is completely customizable by the Sysop. ModemBase Pro can display your data any way you want with its WYSIWYG (What You See Is What You Get) FORMS that support all caller terminal types from text to RIP graphics. ModemBase Pro does not require you to design your own interface and will dynamically adapt to any xBase compatible database. ModemBase Pro is not a fully relational database engine because of its simplistic approach. Relational database theory is inherently complex. Instead, ModemBase Pro offers easy-to-use relational link types for linking to pop- up choice lists, tables, and groups that 3 can be used when gathering data on-line. Relational links when viewing data will be available in release 2.0. ModemBase Pro does not use .PRG programming files, nor does it compile into a distributable application. ModemBase Pro ________ DOES NOT require DOORWAY or any other communication re-director. ModemBase Pro has built-in support for standard and nonstandard communication ports, Digiboards, and fossil drivers. ModemBase Pro does not limit you to the number of nodes you may run. Your purchased registered copy of ModemBase Pro entitles you to unlimited nodes, as long as all your nodes are at a single site location. A separate purchased copy of ModemBase Pro is required for each separate site within an organization. You may not distribute copies of ModemBase Pro to others so that they can run your database designs. You may, however, distribute MBMANAGE freely, which provides limited database management. ModemBase Pro is not written in any 4GL (4th generation language). ModemBase Pro is written entirely in C++ and assembly using Borland C++. ModemBase Pro is a professional toolkit for interfacing databases to the on-line world for non-programmers. Modem Base Pro delivers many powerful features you would expect from a completed database application and seamlessly handles the nuances of dealing with on-line communications. Modem Base Pro is not intended to replace existing local database programs or toolkits, but rather work together with them to offer an on-line interface to existing or new database files that your callers will find easy to use. 4 Chapter 1 ModemBase Pro Concept The information age is upon us. The overwhelming success of the on-line industry is evidence of this. System Operators (Sysops) of on-line systems, more commonly known as Bulletin Board Systems (BBS's), are realizing the power they possess every day as this technology progresses. It is now possible to easily put information on-line in a real-time environment so that callers can access that information remotely via modem. ModemBase Pro is a complete on-line Database Management System (DBMS) that's versatile, yet easy-to-use for the both the Sysop and Caller. Database management is not a new concept, but focusing on quality on-line database management has been a recent dilemma for the on-line industry. ModemBase Pro offers a solution. ModemBase Pro is for you if you want to gather, store, and/or display information with an existing on-line system. ModemBase Pro is compatible with most systems and integration is fairly easy. Your database can be on-line in approximately 10-15 minutes once some basic concepts are learned. Information comes in many forms and types. ModemBase Pro can store information in a commonly used database file that conforms to dBase III specifications. This file format allows you to customize a database so that the information stored in the file is specific to your needs, providing unlimited applications. The decision to comply with dBase III file format allows increased flexibility for putting existing databases on-line that may be easily shared with other applications. There are hundreds of programs that support dBase III file formats. 5 A dBase III file by itself however, does not do much more than store information in a specified file format. Modem Base Pro provides the caller with a common on-line user interface to your database. ModemBase Pro lets you utilize new or existing database files by providing the needed tools for on-line use. These tools come in the form of two programs: ModemBase Master (MBMASTER) and ModemBase Access (MBACCESS). MBMASTER is a small database management utility that is provided as a tool for those that may not have access to any other database management software. MBMASTER can create new database files that can then be used by MBACCESS. MBMASTER is actually a special mode of operation of MBACCESS that takes your database file and helps hand-hold you through the setup of putting it on-line. MBMASTER is responsible for creating all the necessary support files that MBACCESS will use to interface your database to your on-line caller. MBACCESS provides the on-line interface between your caller and your database. Remember, a database file does nothing more than store your information. MBACCESS provides a system that allows you to gather or display information on- line. MBACCESS utilizes configuration, linkage, user profile, choice, and support databases that are created and configured when using MBMASTER. These "support databases" offer instructions to MBACCESS on how to process your "main database". MBACCESS gives your database intelligence that you can control. It also provides a default interface so that you can put a database on- 6 line in just a few minutes and customize as your needs progress. MBACCESS is commonly referred to as a "DOOR" that links an on-line system to your database. Using ModemBase Pro you can create customized information databases for many different applications ranging from customer lists to information retrieval systems. It supports most existing on-line systems and BBS's and provides complete multi-user access at both the database and communication levels. It also supports multiple hardware platforms ranging from standard communication serial ports and nonstandard communication serial ports, to Digiboards and fossil drivers. ModemBase Pro is a complete professional on-line Database System for the non-programmer and non-database developer. ModemBase Pro is frequently used by hard core database programmers to help increase productivity and turn complex on-line database projects into complete integrated on-line solutions at a fraction of the time and cost. Every day people are finding exciting new applications for ModemBase Pro as a business productivity tool or to help produce income. What will you be using ModemBase Pro for? [***HAT IMAGE PG 7] 7 This page is intentionally blank. 8 Chapter 2 DATABASE PRIMER If you are already familiar with database development and theory, this chapter may be a good refresher for even the advanced database management user. Additionally, this database primer builds upon concepts that are specific only to MBACCESS and it is highly recommended that you take the time to read it thoroughly. Whether you're using MBACCESS to allow access to a new database or an existing one, advanced planning is the key to any successful database. A ``DATABASE'' is nothing more than a collection of DATA about a particular SUBJECT. For example, an address book is used to keep certain information about people, like phone number, address, and possibly birthdate or anniversary. If we wanted to put our address book in the computer, we would need to design a database to store the information about each person in our address book. The information on each person is called DATA and the person the information is about is our SUBJECT. The example databases included with MBPRO and referenced throughout this manual have both a SUBJECT and DATA. For example, in the sample airplanes database (\MBPRO20\ONLINE\AERO\JETS.DBF) included as the demo database, the SUBJECT is the airplanes. The information that is displayed from the database is stored in a database record in the file called JETS.DBF. 9 SUBJECT and contains DATA about that SUBJECT the SUBJECT being airplanes and DATA being the information about the airplanes. Like a file cabinet where we would store file folders on each of our customers, a database is similar. A database is a collection of records compared to a file cabinet, which is a collection of file folders. Each record in a database is similar to that of a file folder. The contents within the record contain DATA about our SUBJECT. An organized file folder might have a chart containing the name of the customer, address, and other pertinent information. The same applies for our database file. Figure 2-1 shows the actual record layout of the JETS.DBF file as viewed using MBACCESS. [***Figure2-1 PG 10] Each record is analogous to the file folder and the record layout is analogous to the chart inside the file folder. The record layout is the design of our database and in this example contains information about AIRPLANES. Figure 2-1 above shows the actual record layout as displayed while in record view mode using MBACCESS. Do not be too concerned with all the items on the record view screen at the moment, MBACCESS will be 10 discussed in more detail as you proceed through this manual. For now, it is important to notice the field items in our record layout. Just like our file cabinet that has many file folders, our database can have many records in it. ModemBase Pro supports up to 2 billion records in a single database. The advantage the computer has over the file cabinet should be obvious, but will be explained in more detail next. The computer can quickly manage records within a database, such as adding, deleting, searching, sorting, and browsing. For example, it is usually cumbersome to search for all occurrences of the word "contractor" in a file cabinet full of file folders. On the other hand, using a database on the computer can quickly search and retrieve each occurrence. The added bonus of using ModemBase Pro is that your file cabinet can be on-line and is the first database of its kind to allow remote access to data in such an easy-to-use, yet powerful environment. When you decide to create a database, you need to organize your thoughts and figure out what your SUBJECT and are DATA and how they relate to one another. You may want to collect or display DATA about a particular SUBJECT and you may even have different SUBJECTS that relate with one another. For example, if you manufacture widgets you might be interested in setting up an on-line database in which people can call in and place an order for the various widgets you make. In this case, we have two different SUBJECTS: WIDGETS and ORDERS. That means we need to create two different databases, one for WIDGETS and the other for ORDERS. These two databases will hold DATA and contain information about our SUBJECTS. 11 Let's continue onward with our WIDGET analogy. With both of our SUBJECTS now figured out, we need to go one step further and examine how the two SUBJECTS: (WIDGETS and ORDERS) relate to one another. Is the WIDGET database going to have data about our customer's order? Of course not. The ORDER database will have DATA about the customer and also which widgets the customer ordered, but will not be a database of widgets. The separate WIDGET database will have DATA about our WIDGETS. Remember, they are separate databases with separate SUBJECTS and DATA. But what about our customer's personal information, such as billing address and phone number? We will want some way of storing information about our customers that can be used over and over again when placing an order. You may want to design another database, but ModemBase Pro uses a Default User Profile database system which will easily and automatically store data which you want repeated between orders. ModemBase Pro helps simplify this concept by allowing you to combine the customer information and actual ordered items into one MAIN database. A separate DEFAULT USER PROFILE database contains the individual customer data that will be repeated between orders. Chapter 8 covers the Default User Profile system in more detail, but the basic concept of how the DEFAULT USER PROFILE database operates is fairly straightforward. The DEFAULT USER PROFILE database is simply a duplicate record structure of your MAIN database. In this case, the DEFAULT USER PROFILE database would be a duplicate of our ORDER database. Any fields you want Modem Base Pro to repeat data between orders, you set the fields as a REPEAT TYPE 12 (See Chapter 7). Repeat data will automatically be repeated. Information, such as the callers name, address, and phone number can be stored and retrieved with default information. That means every time the customer places an order, MBACCESS has the capability to look up the callers profile and if one exists pull the default information into the record. If MBACCESS doesn't find a DEFAULT USER , then MBACCESS will ask the caller for the PROFILE information contained in the user profile and store it for use during future on-line sessions. Information within the USER PROFILE is completely configurable within the design of your MAIN database and the caller can edit their DEFAULT USER PROFILE information on-line via the main selection menu. This type of SMART `` processing is what gives you '' the power to make your on-line database come alive for your caller. You can run the MBPRO order entry demonstration to see how it intuitively leads the caller through the database design during the information gathering process. These types of features should be kept in mind while designing your database for on-line usage so that you may exploit this power to your best interest. The ORDER database will also need to allow the customer to choose from the database and put the selected WIDGET widget in a corresponding linked field within the ORDER database. In ModemBase Pro this is accomplished by using a separate CHOICE database. Any field in your main database can easily be linked to a corresponding CHOICE database and display a pop-up list of selections to your caller. The caller then selects one of the available choices, in this case a widget, and the selection is placed into the linked field in the main database, in this case the ORDER database. 13 A common mistake often made by beginner database developers is to try to combine more than one SUBJECT per database. For example, there is no physical way we could have possibly combined the widget database with the order database. This is an easy mistake to make, but can prove to be clumsy and usually doesn't offer any flexibility. It wouldn't be very wise to include DATA fields about the cost price of each of our widgets in our database record layout. Each ORDER customer may have an unlimited number of orders. So, the moral of our story is that we need to keep our as SUBJECTS separated as possible when designing our databases. That leaves us now with two : SUBJECTS 1) ORDERS 2) WIDGETS Let's not get too overly concerned right away with the exact record layout of each of these databases. Let's first think a little bit about how these databases relate to one another. Perhaps, you have heard the term "Relational Databases" before? What the relationship between each of these databases is what we must figure out. To help us figure out how each database relates to one another, we should first analyze what our GOAL is. We need to get our customer's order of widgets, right? Our ORDER database will need to get and store repeat information about our customer (in ModemBase Pro this data is stored in a database referred to as the Default User Profile database) telling us who is placing the order and how to bill it, ship it, and any other repeat information that has been defined. That means our ORDER data- 14 base will use DATA found in these other databases to complete an order. So... It looks like our ORDER database is our ultimate GOAL. That means our GOAL database is our database and the MAIN terms GOAL MAIN and database are used interchangeably and have the same meaning. Thus, the key to any database development project is determining just exactly what the is and how each GOAL SUBJECT relates to one another to achieve that . We have done just that. GOAL So what do we have? Nothing yet, really. Just a concept, but the conceptual design of your database is by far the most important step towards making a successful database RECORD LAYOUT structure. Like an organized file cabinet, an organized and well-planned database makes it easier to manage. On the other hand, a messy file cabinet or a poorly planned database makes it difficult to manage and may be confusing to your callers or even the creator. Planning your database properly can save many hours of frustration later on. Refer to Figure 2-2 ORDER.DBF record structure as displayed using MBACCESS for an example. [***Figure 2-2 PG 15] 15 Refer to the \MBPRO\DEMO\ORDER\ORDER.DBF database file for additional fields within the ORDER.DBF record layout structure not shown in Figure 2-2. To summarize, we now have figured out that our main is GOAL our ORDER database. Our GOAL database is almost always the database. The other databases relate to our MAIN MAIN database and ultimately we have several databases that work together to produce the desired results. The next chapter (Chapter 3 - Getting Started) will walk you through an actual step-by-step process of configuring a database for on-line usage. For now, you should understand the basic concepts of what a database is, the importance of a well organized record layout, and the relationships between and SUBJECTS DATA. Section II - MBMANAGE discusses in detail the actual creation of a database and the steps involved. Once a database is created with an organized record layout, the steps highlighted in Chapter 3 will allow you to put your database on-line using COMPOSER. Once configuration of your database is completed using COMPOSER, you will use MBACCESS to interface your database to the on- line world and provide an easy-to-use system for your caller to access your database. 16 Chapter 3 Getting Started - the Light Bulb! This chapter discusses the necessary steps to put a database on-line in a detailed overview format. A quick start guide is provided, as well as information on how to hook your database to an existing on-line system. Consider this the "light bulb" chapter. The metaphorical light bulb should click on as you read this chapter. That means that you should not proceed past this chapter unless this makes sense to you. The rest of the chapters in this manual only extrapolate on the information provided in this chapter and build from its foundation. Operational Requirements HARDWARE: Starting with ModemBase Pro release 1.70, XT class machines using an 8088/8086 CPU will NO LONGER BE SUPPORTED! AT class machines using 80286 or better CPU (80386, 80486, PENTIUM, or compatible 80x86 cpu) will be required to use ModemBase Pro. ModemBase Pro release 1.60 is the last release that will support XT class machines. There are several reasons for this and most have to do with performance and memory management which is severely limited on an XT class machine. MEMORY: ModemBase Pro has been designed to be easy-to-use, setup, and run. ModemBase Pro uses a sophisticated memory management process developed by Borland International called VROOMM which stands for Virtual Runtime Object Oriented Memory Management. You won't find any settings for swapping to EMS/XMS/DISK or the ability to set the overlay buffer size. ModemBase Pro will interrogate each system and 17 use the memory management mode best for that system. A system with EMS or XMS memory will perform much better than one without. If ModemBase Pro does not find any active EMS or XMS memory to use, it will swap memory to disk when needed. ModemBase Pro requires a MINIMUM BASE MEMORY of 384K to operate. Using the VROOMM technology, ModemBase Pro is actually larger than 384K in size, but is able to swap memory modules seamlessly without any user intervention. No .OVL overlay files are needed with VROOMM technology either. All the overlays are built into the single MBACCESS.EXE. ModemBase Pro has been tested to work properly on a wide variety of hardware and various operating systems, including networks, OS/2, all flavors of WINDOWS, Novell Dos, Desqview, and more. The only thing you need to worry about is base conventional memory. ModemBase Pro must have at least 384K of memory to use after shelling from a BBS, any other program, or running in local mode. Anything between 350K-384K may work properly at first, but you may run out of memory while ModemBase is being used, because it dynamically allocates memory as needed during searches, viewing memos (large 64K memos may require as much as 450K of base memory in order to view the memo), Transfers ([X]fer), and remote-to-host database appending. Fortunately, most systems today will have 500K plus base memory after shelling and swapping to DOS to run ModemBase Pro and you will probably never have to worry about memory when using ModemBase Pro. DISK SPACE REQUIREMENTS : ModemBase Pro installed fresh requires under 3 megs of hard disk space. Each application of ModemBase is different and 18 disk space requirements vary with the number of on-line databases in use and the size of each database. The amount of free disk space can quickly become a consideration when using large databases. Searches and transfers on large databases may require a large amount of free disk space needed to create temporary files used to generate search tables, transfer reports, transfer databases, file attachments, and other work files. Each node on a multi- user system also uses separate individual work directories. Large, multi-user systems may also require additional free disk space for each node's work directory. As you can see, many factors determine exactly how much disk space is required as well as free disk space and each ModemBase Pro application is different. Keep in mind also that databases tend to grow, of course, as records are added. It is good practice to periodically reevaluate free disk space requirements and expand your system as needed. Quick Start Installation ________________________________________ Put Installation Disk into Floppy Drive. 1) Insert your installation disk in either DRIVE A: OR B: then change to that drive, by typing A: or B: <ENTER> depending on which drive you put the installation disk into. There are two files on the installation disk, INSTALL.COM and MBPRO.EXE. 2) ____________________________ ModemBase Pro Installation. At the DOS PROMPT type INSTALL and press <ENTER>. On-Screen instructions will appear to assist you. You will be asked for the directory in which you want to install ModemBase Pro to. Typically, this is the C:\MBPRO directory. Type C:\MBPRO and <ENTER>. 19 3) _______________________ ModemBase Pro Composer Once step 2 is complete and MBPRO has been installed, you may setup an existing database for on-line usage by typing COMPOSER. COMPOSER contains complete on-screen instructions and will ask you for the following information : [***Figure 3-1 PG 20] Database Filename. Refer to Figure 3-1. Your database filename 6 characters or less. You will need to _______ must be enter your database filename _______ without the filename extension or path, i.e. if your database is PARTS.DBF, you will only enter PARTS as your database filename. COMPOSER will use this filename to create the necessary CONFIGURATION LINK , , and SUPPORT files that will then be used by MBACCESS to interface your database to your on-line caller. Use to create a new database if you do not have an existing database to put on-line. Database Directory. Refer to Figure 3-1. You will then be asked for the directory location of your database you will be putting on-line, i.e., C:\DATA. If COMPOSER can not find your database file, it will ask you to try again. 20 You may try again or press CTRL-C to abort the operation at any time. On-line Database Installation Directory. Refer to Figure 3- 1. This directory should be a separate directory from that of your MBPRO directory and will be where COMPOSER sets up your database for on-line usage and creates all the necessary support files. Your database file will be copied from the previous entered database directory to this on-line database installation directory. Caution! If your database is very large this may not be desired, and you may want to use the same directory as your database if possible. COMPOSER will attempt to create the directory to install to if it does not exist and if it can not create the directory, it will ask you to try again. Once your database is installed by COMPOSER, you will proceed to setup your NODE CONFIGURATION and LINK CONFIGURATION. There is on-screen instructions for this process and you should refer to Chapter 5-8 for in-depth database design and configuration concepts, features, and usage. CONFIGURATION DATABASE. Refer to Chapter 6 for detailed explanation of each field in the configuration database. You will first be asked to setup the configuration database. Once at the COMPOSER Main Menu you can either [A]dd or [B]rowse records in the configuration database. Since it is your first time setting up your configuration database, either selection will initiate a default node configuration. Answer each question for each field, being sure to carefully read the field instructions. You may use the default information that is provided during the configuration for a quick and easy setup. As soon as the default node is setup you 21 will be asked for the COMPORT OVERRIDE and DOOR.SYS PATH information for record #1. All other information will be retrieved from the default node setup. It is important to realize that each record in the configuration database configures a node in a multi-node system. If you have 4 nodes, you will need 4 configuration records with the exception of autonode operation which allows you to use a single configuration record for all nodes. If you are running a single node system then you will only need to configure record #1. When you load MBACCESS from the command line, the node number is passed as a command line parameter and the appropriate node configuration record is loaded. If you are using nonstandard communication ports, Digiboards, or Fossil driver for your on-line system, you will need to set the COMPORT OVERRIDE for each node (unless using autonode). This is usually the port number when using Digiboards or Fossil Drivers. You need to leave the COMPORT OVERRIDE field blank if you are using standard communication ports such as COM1-COM4. The node communication port will then be read from the door information file provided by the on-line system. Each node properly point to a valid must door information file, i.e. DOOR.SYS. Make sure the DOOR.SYS PATH field is properly set with a complete PATH and FILENAME or you will receive an error when trying to load MBACCESS. You should also realize that most on-line systems only create the door information file when a caller actually opens a DOOR. If you want to setup your database for local testing, you can either run your on-line system in local mode or simply put DOOR.SYS and MBACCESS will use the DOOR.SYS that is provided for testing purposes in your installed database current directory. COMPOSER creates an example DOOR.BAT file in your installed database directory that 22 will contain the command line parameters necessary to run your database with MBACCESS. When you are finished with composer you can edit this DOOR.BAT file to work with your on-line system. You will need to [A]dd a record to the configuration database for each node in your system, unless using autonode. By having separate configuration records for each node, you have the flexibility of customizing each nodes configuration information. If there is no need to have different configuration information between nodes, you should use the autonode feature and configure only one single record in the configuration database. You will then pass an "A" for autonode on the command line to MBACCESS instead of the node number. Adding multiple configuration records for multiple node is made easy because of the use of a default node setup. You can [B]rowse/View/Edit the configuration database from the COMPOSER Main Menu and this will allow you to make any specific customization node changes once a node is [A]dded to the configuration database. When finished you may [Q]uit from COMPOSER. LINKAGE DATABASE . Refer to Chapter 7 for detailed explanation of each field in the linkage database. Once the configuration database is setup, you have the option of utilizing the power within the ModemBase Linkage system. If your database is going to be used on-line to gather information, then you will probably want to utilize many of the features within the Linkage System. The Linkage database provides instructions to MBACCESS when processing your "main database". Each record in the Linkage database configures a field in your main database. ___________ This is an __________________ important concept. In other words, Record #1 in the Linkage database provides instructions to MBACCESS on how 23 to process Field #1 in your main database. Record #2 in the Linkage database provides instructions to MBACCESS on how to process Field #2 in your main database and so on. This is an optional database and you are not required to [A]dd any records to the Linkage database, but you may want to provide at least enhanced field descriptions. If you have 10 fields in your main database you should [A]dd 10 records to the Linkage database. If a record does not exist for a field, however, ModemBase will not complain. 4) Editing and using the example DOOR.BAT file. An example DOOR.BAT file is created by COMPOSER and will reside in your installed database directory. This DOOR.BAT file contains the necessary command line parameters to run your database, however usually needs to be edited to work with your on-line system. Most on-line systems support the ability to shell to a DOS session (known as running a DOOR). You may need to change the name of the DOOR.BAT file to correspond to your on-line system requirements. Here is an example DOOR.BAT file : C: CD \MBPRO\DATA MBACCESS TESTC.DBF 1 Notice that the batch file first changes to the drive and directory of where your installed database file is located, then executes MBACCESS passing it the appropriate command line parameters: first the name of the configuration database, and second the node number. This DOOR.BAT file loads the configuration record for node 1. Multi-node systems should use an environment variable such as %WCNODEID% which is used 24 with Wildcat! BBS systems in place of the node number, i.e.; MBACCESS TESTC.DBF %WCNODEID%. If you are using autonode, you should pass a letter "A" instead of a node number. IMPORTANT! If you are using autonode, you MUST NOT change directories in your batch file. Autonode is only able to work properly if MBACCESS executes from the nodes current work directory. Your DOOR.BAT file must then call MBACCESS without changing directories. MBACCESS can then read in the DOOR.SYS file (or other door information file) from the current node work directory and figure out which node it is on. Autonode will read in the configuration record #1 within the configuration database and will handle all multi-node issues automatically. An example autonode DOOR.BAT file would contain only a single line and look like this : \MBPRO\MBACCESS C:\MBPRO\TEST\TESTC.DBF A ________________________________ ModemBase Pro Manage (MBMANAGE) 5) ModemBase Pro Manage (MBMANAGE) is a Database Management Utility (DBMS) that can be used to create new databases in dBase III compatible format. You may also use MBMANAGE to add, edit, browse, or search your existing databases. MBMANAGE is also used to Clean/Pack databases by removing records marked for deletion. See the manual under Section II for more information on using MBMANAGE. _____________________________________________ Read CHANGES.DOC for all additional features. 6) Your manual offers detailed information on the use and functionality of ModemBase Pro. We have put together an additional document however, explaining various TIPS on putting your database on-line, along 25 with details on many new features that were added after the manual went to print, and common questions and answers. 6) ________________________________________ Technical Support Services (9am-5pm PST) Call 909-699-2216 for voice support or 909-696-2212 for 24 hour Bulletin Board System (BBS). You may also send e-mail to tgetty@netconnx.com via the internet. 26 MBACCESS - THE DOOR WHAT IS A DOOR? A BBS `` '' DOOR has derived its name because of the way it functions. Just like a real door that provides an opening from one place to another, BBS's often offer DOORS to access other programs from the main BBS. MBACCESS is such that it is called a `` DOOR . Think of a BBS '' as simply a DOOR portal or gateway to another program application. Your BBS software must support access in order to use MBACCESS. DOOR DOOR COMPATIBILITY MBACCESS is DOOR.SYS compatible and also supports other BBS's as listed below or any BBS conforming to the DOOR.SYS format standards. MBACCESS reads information as provided by DOOR.SYS to allow the Sysop to configure databases which may utilize this information, even BBS's that do not conform to one of these many types listed below : ________ BBS TYPE _____ _____ __ _____________ DOOR FILENAME Wildcat (2.x) CALLINFO.BBS Wildcat (3.x-4.x) DOOR.SYS GAP DOOR.SYS Searchlight DOOR.SYS SpitFire(3.x) DOOR.SYS RBBS-PC DORINFOx.DEF Quick BBS DORINFOx.DEF RA Remote Access DORINFOx.DEF PCBoard(12-14.x) PCBOARD.SYS WWIV CHAIN.TXT GENERIC GENERIC.SYS (and others supporting any above formats.) 27 An example of each of the above DOOR files is provided along with MBPRO for testing purposes. See examples of each in the \MBPRO\DOORTEST subdirectory. MBACCESS DOOR Interface MBACCESS is a state of the art door program. MBACCESS is fully capable of linking with most BBS programs by providing standard and configurable comport settings, fossil, and/or Digiboards driver support. This provides tremendous support for a variety of different hardware platforms. To Load MBACCESS type: M B A C C E S S [ c o n f i g . d b f ] [ n o d e # ] Once MBACCESS loads it takes complete control over your caller. MBACCESS completely monitors modem carrier and will reliably cycle your caller if there is a disruption in connection and return gracefully to the BBS and properly close all database files in the process. With its ability to provide both multi-user access to the door and the database files, MBACCESS is in a class all by itsself! While the caller is in MBACCESS, several Sysop Features are available and can be displayed by typing for HELP on ALT-H the local door console. When the door is running you will notice a two line status display at the bottom of the local screen indicating the following information at a glance : [***Status Line PG 28] 28 Pressing Alt-H will Toggle the status line display to view the following Function Key commands available and ALT key commands : ALT-N Sysop Next to Use Door ALT-X Dos Exit after call logs off F3 All Screen Output to Printer F4 Sysop Page Toggle ON/OFF F7 Alarm Toggle ON/OFF F8 Force caller to logoff NOW F9 Status Display Toggle F10 Chat with Caller Pressing Alt-H again will toggle the status line display to view the comport configuration information. After a few seconds the status line will return to the first status line display format above. MBACCESS is a full featured door program packed with advanced but easy to use features that ensures your door operations will be as reliable (sometimes even more reliable) as your BBS operations. MBACCESS will cycle a caller after x # of minutes of inactivity and signal the remote caller with a beep sound every x # of minutes to warn of inactivity. This important feature will prevent any remote sessions from becoming inactive and tying up the system for extended periods of time. (Times may be modified in configuration files.) MBACCESS provides you worry free on-line database processing for your dBase compatible files. Summary : At this point, the "light bulb" should have clicked on. You should have a good understanding of the mechanisms and concepts of ModemBase Pro and it's related programs. In the chapters ahead you will learn about the specifics of the configuration, linkage, default user profile databases, and advanced concepts. 29 You should now understand the concepts presented in Chapters 1 through 3. Before moving on, you should know the answers to the following questions : What is a database? 1) 2) What program is used to generate a new database and record layout with fields which will contain data? What is a door? 3) What program is used as the door? 4) What are the command line parameters used to start 5) MBACCESS? What is autonode? 6) 7) What is a configuration database? 8)What is a linkage database? 9)What will composer do? 10) What is a DOOR.BAT file and DOOR.SYS path? 11) What is a default user profile database used for? If you missed any of these questions, you should reread Chapters 1-3 or call technical support at 909-699-2216! 30 Chapter 4 Security Access MBACCESS is the on-line interface to your database. It is often desired to control the type of access to your database. In this Chapter you will learn about the different access categories, such as Add, Edit, View, and Xfer (transfer). These different access categories and additional modes of operation control the caller's access to your database. We are discussing these concepts first before delving into the configuration, linkage, and default user profile database in chapters 6-8, because it is important to have an understanding of the types of security access available to you when designing and configuring your database. The knowledge gained in this chapter will help you set up both your configuration and linkage databases. MBACCESS OPERATIONAL CATEGORIES Security access in ModemBase Pro is actually a simple concept. The operational categories specify the different types of access available to the caller. There are four operational categories : 1) Add 2) Edit 3) View 4) Xfer (transfer) Additionally, each of these categories offer various modes of access, which is explained next. Security 31 access can be defined at both the record level and field level. That means that the above operational categories apply to overall record level access (defined in the configuration database) and field level access (defined in the linkage database). This means you can control access to a record and also to a field. For example, you may want a caller to be able to edit only records he owns, but there may be a field or two you do not want him to be able to edit. In this case, you will set the edit access within the configuration database to owner access and set the field access to no access within the linkage database on the fields you do not want edited. Now the caller can edit his own record, but not the fields he does not have access to. Security Modes of Access With the exception of the Xfer category, all other categories : Add, Edit, and View; have the same security modes of Access : ______ Access _ ____ Mode 0 No Access 1 Full Access 2 Owner Access Xfer Security Access Modes ModemBase Pro handles all the setup for file transfers, including making default WORK and ATTACH paths, and even a built-in dynamic report generator. There are several Xfer modes available. Here is a brief list of all the features available for file transfers : 1) ALL download transfer modes are configurable by the Sysop with 8 different transfer modes that com- 32 bine with View Security to provide optimum configuration for various needs. 2) Allows downloading of Text Report of Current or All records that caller has access to. 3) Allows downloading of main or search database tables, including support for downloading .DBT memo files if they exist. 4) Allows downloading of file attachments for current record, including multiple file attachments per record. 5) Sysop-configurable support for up to four popular compression programs or allows caller to select from any of the four while on-line. 6) Downloads require an external file transfer protocol program to function properly, such as DSZ by Omen Technologies or other compatible DSZ programs. NetConnX is developing its own external file transfer protocol called DigiZ and is scheduled to be released with version 2.0. There is also an available XFERKIT.ZIP available for download via NetConnX BBS. 7) Automatically handles multi-node work files and automatic generation of a dynamic record report even if you don't create your own customized report format. 8) Reports missing file attachments to ERROR.LOG. 9) Caller can [S]elect protocol from Main Menu or at time of download if [S]elect protocol was passed from BBS, otherwise ModemBase Pro will use the callers default protocol as passed from the BBS. Now, let's get into some details about the File Transfer System for allowing your callers to download records from your database in either a customizable 33 report format or an actual dBase III compatible file. The [X]fer option will ONLY be displayed to the caller if you have enabled the XFER SECURITY MODE with 1 of 8 different settings. The caller will only be able to [X]fer records that he or she has VIEW access to as defined by the VIEW SECURITY MODE The 8 different Transfer Security Modes are as follows : 0 - Disable Transfer Capability 1 - Allow REPORT TEXT transfers ONLY 2 - Allow DATABASE transfers ONLY 3 - Allow FILE ATTACHMENT transfers ONLY 4 - REPORT TEXT and DATABASE transfers OK 5 - REPORT TEXT and FILE ATTACHMENT OK 6 - DATABASE and FILE ATTACHMENT OK 7 - ALL TRANSFERS ALLOWED Knowing in advance which type of security access you want your callers to have to your databases will help make your setup and configuration go smoother. It is important to note the relationship between record level security and field level security. Record level security categories are controlled by modes of access to the record. Field level security on the other hand allows you to specify a security level for that category on a per field basis. That means that you can control access to a specific record and also specific fields. For example, let's assume we have a database in which we want callers to be able to add as many records as they want, only edit their own records they added, but be able to view all records in the database. ModemBase Pro can do this with ease, by setting Add access to full, Edit access to owner, and View access to full. Additionally, let's say there were some fields in the database you didn't want certain people to view or edit once added to the system. You could do this in the linkage database 34 by specifying a field security level for view and edit. Combining security modes can offer a variety of data protection solutions for any database design. 35 [***TECH TIPS FLAG IMAGE] Security Access Tech Tips : When using security access modes realize that if you are accessing the database at Sysop level or above as defined in the configuration database, you will have full access to the database and Sysop level overrides any security access settings. Be sure to either login to your database at lower than Sysop level or set your Sysop level high for testing purposes. We receive many technical support calls from customers complaining that their security access is not working. If you are at Sysop level or higher, you will have full access to the database and it may appear that you have this symptom. Indeed, it is not that case. Please keep this in mind during testing and development of your database. Remember, the Sysop level is displayed on the MBACCESS status line for the current caller. You can set the Sysop level access within the configuration database. Any callers equal to or greater than the configured Sysop level will have full access to the database regardless of security settings. Use caution when setting the Sysop level to ensure security. 36 ModemBase Pro is a collection of database files that work together in order to display or gather information on-line. There are a few support databases and display files that enhance the operation of a database and how it appears to the caller. Great care has been taken to provide you with the necessary tools to create an on-line database system that looks like a custom written database application requiring hundreds or even thousands of man hours to design and program. Literally, thousands of man hours have gone into the design of ModemBase Pro and we have done most of the hard work for you so that you can concentrate on the finished project and worry about how you want data displayed or gathered to or from your caller. Realize also that "out of the box", ModemBase Pro has built-in dynamic display mechanisms so that it will work without any customization at all and you can put a database on-line in a few minutes. Knowing which files do what, however, will help you manage your database better and allow you to create a customized look that is unique to your application. At the heart of any on-line database is the physical MAIN database file. Previous chapters have explained the relationship between the MAIN database file and the configuration and linkage databases. ModemBase Pro uses a system which keys off of the first 6 characters of the MAIN database filename to generate a configuration, linkage, and default user profile database. Other databases come into play when your database design 37 requires pop-up choice lists in which the caller can be provided with a list of selections. Other files are used to provide interactive help display files when gathering data from a caller. A separate welcome and main menu file is provided to customize what the caller sees throughout the entire on-line interaction. Best of all, the record view form allows you to generate data displays that are specific to your application and seamlessly work for all callers terminal types, such as text, ansi, and RIP graphics. Below is a list of all these files that are part of the ModemBase Pro System and how they interact. We will use a MAIN database filename of MBPRO.DBF for this example. ________ Filename__ ___________ Description MBPRO.DBF MAIN database filename MBPROC.DBF Configuration database filename MBPROL.DBF Linkage database filename MBPROS.DBF Default User Profile database MBPRO.1 Display file for field 1 on adding. MBPRO.2 Display file for field 2 on adding. MBPRO.3 and so on, up to total fields. WELCOME.XXX Welcome file MAINMENU.XXX Main menu display file PROMPTS.XXX Prompts file FORM.XXX Record view form file. PROMPT.XXX Command prompt replace display STARTADD.XXX Displays before adding record ENDADD.XXX Displays after adding record ENDEDIT.XXX Displays after editing record 38 ENDUSER1.XXX Displays first time creating user profile. ENDUSER.XXX Displays after editing user profile. HELP.XXX Displays caller help file. HELPMEMO.XXX Displays caller help on memos file. TABLE.XXX Displays to explain [G]o and [T]able search. SEARCH.XXX Displays for Fast or Slow searches SORT.XXX Displays when s[O]rting before sort list. DISPLAY.XXX Displays instructions from main menu. ACTIVITY.DBF Logs records viewed and callers name. ERROR.LOG Logs system errors. Note : All other files are COMPOSER support files and are located in the COMPOSER subdirectory. Older versions of ModemBase Pro mixed the COMPOSER support files with the above files. This version of ModemBase Pro separates the COMPOSER files to help clear up any clutter. When editing a field ModemBase Pro will look for a display file that corresponds to the callers graphics mode. A field display file is a file that is displayed to the caller while gathering information on-line by adding a record to the database. Your xBase files can have up to 128 fields (dBase III limitation). Each field can have a corresponding display file. Since ModemBase Pro keys its support files from the first 6 characters of the MAIN database filename, it will use the additional two characters to determine which type of field display file to look for depending on which graphics mode the caller supports. The file extension contains the field number of the corresponding input field. ModemBase Pro will also use the field help display 39 files when editing a field. MBACCESS will look for the XXXXXXE.### where XXXXXX is the main database filename and ### is the corresponding field number. The `E' indicates that this is a field Edit display file. If the XXXXXXE.### file is not found then ModemBase will use the XXXXXX.### file instead. You may wonder why we just don't display the XXXXXX.### file that is used when [A]DDING a record to the database. The reason is simple. It is very probable that Sysops will want to have different display files for [A]dding and different display files for editing specific fields. A lot of times they may be the same however, so if you don't create the XXXXXXE.### display file and if XXXXXX.### file exists, the XXXXXX.### file will be displayed. Here is a recap of the different display files MBACCESS will look for and in what mode they are used. xxxxxx.### Normal Field Help Display File. Used when adding or when editing (when editing ModemBase Pro first looks for a xxxxxxE.### file and if it is not found will display this file instead). This file is also displayed during the creation of a default user profile if the xxxxxxD.### file is not found. xxxxxxE.### Field Edit Display File first looked for when editing a single field. If this file is not found, xxxxxx.### will be looked for and displayed if found. xxxxxxD.### Default User Profile Field Display File first looked for when updating or adding new Default User Profile fields. If this file is not found, then NOTHING WILL BE 40 DISPLAYED except for the Field Description. xxxxxxR.### RIPSCRIP file to be displayed for field when adding records. xxxxxxER.### RIPSCRIP file to be displayed if the caller is in RIP mode when editing field. xxxxxxDR.### RIPSCRIP file to be displayed if the caller is in RIP mode and updating or adding for the first time Default User Profile fields. If the caller is in RIP MODE and these files are not found, ModemBase Pro will look for the xxxxxx.### Normal Field Help Display File to display instead. The `R' can be used also with the `E' (field Edit) and `D' (Default User Profile) display files. This way you could have RIPSCRIP/ANSI/TEXT versions of your display in order to support each type of caller. xxxxxxG.### ANSI color graphics file looked for first for field Help Display File. If this file is not found, xxxxxx.### Normal Field Help Display File will be used. Only used if the caller has ANSI capabilities. This file is usually not used, but is handy if separate ANSI color and non-color files are required, as well as a separated text only file. xxxxxxEG.### ANSI color graphics file looked for first for field being edited. xxxxxxDG.### 41 ANSI color graphics looked for and displayed when the caller is updating or adding a new Default User Profile record. If not found, ModemBase Pro will then look for the xxxxxx.### file instead. xxxxxxT.### xxxxxxET.### xxxxxxDT.### Same concept as the `G' files above but applies to text mode only callers. As you can see there are many possibilities for specific customization of every aspect of field adding and editing. The database and display files all work together to help bring your database application alive on-line. All display files can easily be edited using any text editor and color codes, or several popular ANSI drawing programs, such as TheDraw by TheSoft Programming Services. TheDraw is available for download as a shareware program on NetConnX BBS via the ModemBase Pro support file area. 42 Chapter 6 Configuration Database Note: Refer to MBPROC.DBF for an example of an actual configuration database. You may access the database either directly using MBMANAGE or via the COMPOSER mode of MBACCESS by going to the \MBPRO\DEMO\MBPRO directory and typing MBPROC. First, we will discuss the record layout of the configuration database, which in this example is the MBPROC.DBF file. The '' C `` in the filename denotes that this is the configuration file for the MAIN database file MBPRO.DBF. The first thing MBACCESS does when it loads is open the configuration file you passed to it from the command line, i.e. MBACCESS MBPROC.DBF 1. The command line tells MBACCESS to load the configuration database, in this case, MBPROC.DBF. The configuration database will then tell MBACCESS several things including what the name of your MAIN database is. Below is a description of each field number in the configuration database file and what it configures. MBPROC.NEW is a blank configuration database with the required record layout and is used to generate a new configuration file for a database during COMPOSER. ______ Field#____ __________ Field Name_____ ___________________________ What each field configures. _ 1 _______ DBFNAME ____ _______________________________ Name of the MAIN database file. ___ In our example it contains MBPRO.DBF which is the name of our MAIN database and tells MBACCESS we will be working with this database. After MBACCESS reads the configuration file, it will read the linkage database and then open this database for processing. It 43 may also contain the database name for a menu choice database containing several database names which may be selected from a menu. (See Field #2 below.) ________ DESCRIPT ____ _ 2 __ _________________________________ Short Description of the database. This description will be displayed on the title bar when the caller is adding, editing, viewing, or searching record(s) on-line. If you put the keyword @ LOADMENU here then the DBFNAME field above contains the name of the menu database to load. MBACCESS will then look for a database in standard choice format (see MENU.DBF for an example empty menu database). Field #1 in the menu database needs to contain the name of a MAIN database to be loaded or the name of yet another LOADMENU. Field #2 in the menu database may contain the name of the description to be displayed to the caller if a MENU.BBS display file is not created and used. Field #3 is unused at this time. To utilize a display menu for your menu database, MBACCESS will look for a .BBS or .RIP file depending on graphics mode with the filename the same as that of the DBFNAME in field #1 above. Each database name from the menu database must be setup using COMPOSER and contain a configuration and linkage database file unless you are loading another LOADMENU database. Advanced menu hierarchy designs are possible, allowing multiple menu levels by simply loading another menu database. See Chapter 10 under the subheading of LOADMENU to learn more about using LOADMENUs. ____ _ 3 ________ OWNFIELD__ _______________ Field# of owner Tells MBACCESS which field in the MAIN database is the owner's name of that record, i.e. this is usually the name of the person as passed from the BBS. If you look at the MBPRO.DBF MAIN database you will see that FIELD #3 is the CONtact Person Name. This OWNFIELD 44 is where we tell MBACCESS which field in the MAIN database is linked to the callers name. In the MBPRO.DBF, Field #3 is the owner field and is defined in the linkage database as NAME link type. That means MBACCESS will automatically a retrieve the caller's name from the BBS door information file and place it into field #3. Then if we place a 3 in this OWNFIELD, MBACCESS will use field #3 to determine who owns each record and control security access to both the MAIN database information and the default user profile. _______ COMPORT ____ _ 4 ___ _________________ Comport override. This is the comport override field and ONLY needs to be used if you are using nonstandard communication ports, fossil driver, or Digiboards. If this field is left blank then MBACCESS will read the comport from the DOOR.SYS file and use standard IRQ and base I/O address settings for COM1- COM4. If you have nonstandard comports, then you need to put your address and IRQ in this field in the following format : PORT:03E8:5. You must use the word PORT along with a colon, then a 4 digit address, another colon, and then the IRQ. This allows MBACCESS to use virtually any nonstandard comport. If you are using the Digiboard or fossil driver then the port # goes here and you will toggle the Digiboard or fossil driver setting below in field #10 or #11. _ 5 _________ LOCALBEEP ____ _ __________ Local beep________ toggle. If this is set to Y the local computer will beep along with the remote computer. If it is set to N (or left blank) then the remote computer will only beep. MBACCESS sends beep warnings to the caller if there is inactivity as set below, or if input exceeds a line length. 45 _ 6____ ________ BEEPTIME _____________________ Inactivity beep time. __ This is the amount of time in minutes that MBACCESS will wait before sending a beep sound to the caller to warn of inactivity. _________ NOUSETIME ____ _ 7 _______________________ Inactivity hangup time. _ This is the amount of time in minutes that MBACCESS will wait before automatically logging the caller off after x minutes of inactivity, i.e. if set to 5 and the above BEEPTIME is set to 1, then if the caller sits on-line without any activity a beep will sound every minute and then after 5 minutes of inactivity the caller will finally be logged off. _______ BBSTYPE ____ _ 8 ____________ Name of BBS. ___ Put the name of your BBS here. This field is currently only useful if using Wildcat or PCboard BBS's. ___________ DOORSYSPATH _ 9____ ____ ________________ Path to DOOR.SYS This is the complete path and filename of where your door information file is located. MBACCESS automatically knows how to handle each of the following door filenames : DOOR.SYS CALLINFO.BBS DORINFOx.BBS CHAINT.TXT PCBOARD.SYS GENERIC.SYS Note: For testing purposes we have included files in the \MBPRO\DOORTEST subdirectory which contains an example of each of these door information files. 46 __ 10___ _________ DIGIBOARD _________________ Digiboard toggle. _ Set this field to Y if using a Digiboard otherwise leave blank or set to N. If you are using a Digiboard or Wildcat! (IM) BBS, then you also need to set the COMPORT OVERRIDE field above to the Digiboard port number for that node, unless you are using autonode. (Remember, each record in the configuration (MPROC.DBF) file corresponds to each node in multi-node usage, i.e., Record #1 is Node #1, Record #2 is Node #2, etc. ) __ 11___ ______ FOSSIL _____________________ Fossil driver toggle. ____ Set this field to Y if using a fossil driver otherwise leave blank or set to N. If you are using a fossil driver (X00, BNU, and DigiFossil has been tested) then you also need to set the COMPORT OVERRRIDE field above to the fossil driver port number for that node. WARNING! DO NOT toggle both DIGIBOARD and FOSSIL fields to Y or MBACCESS will never use FOSSIL. This is especially important to those people using Digiboards with DigiFossil. Digiboard should be set to N and Fossil should be set to Y in that case. ___ __ 12 ______ UPLOAD____ __________________________________ Force caller to upload attachment? Set this field to Y if you are going to use the force upload feature of MBACCESS. This forces callers to attach uploads to records added to a database. The uploaded file is zipped into a unique filename with the JOBNUM of the file and placed into the ATTACHPATH. (Refer to Chapter 10 on File Processing) Note: PKZIP.EXE must be in the path for MBACCESS to properly ZIP the file. The caller may upload his or her files before or after adding record(s) to the database. One file MUST be uploaded for each record if this field is set to Y. 47 __ 13___ ________ WORKPATH ____________________________ Default node work directory. __ The workpath is used often by MBACCESS. If you are going to utilize the force upload feature of MBACCESS which gives the caller the capability of attaching a file upload to a record, then this field contains the FULL path of where you want the uploads to go to during the upload process. (Note: Your DSZ external file transfer protocol program must be registered for this feature to work.) *** WARNING *** All files will be deleted in this directory prior to allowing the upload. DO NOT USE a directory that may contain files which you do not want to be deleted. After the files are uploaded, they will be zipped into a packet with the filename XXXXXXXX.ZIP which is the job number of the record being added. Additionally, for the DOS shell to DSZ to work, COMMAND.COM must be located where your COMSPEC environment variable points to. In most cases this isn't a problem, but is documented here to assist in case you receive an MBPRO -1 error/Dos Error 2. If the caller uploads several files at once, using batch upload protocols, then MBACCESS will list the files that the caller uploaded and add a record to the database, gathering the information from the caller, for each file uploaded. Files uploaded are automatically linked to fields defined with a link type of FILENAM. This field is normally left blank and a NODEx subdirectory workpath will be created and used, where x is the node number. The workpath is also used during file attachment transfers and the ATTACH linktype. __ ___ 14 __________ ATTACHPATH_____ ______________________ File attachments path. _____ This field works in conjunction with the WORKPATH field 13 above when using ATTACH and FILENAM link types. If you are using forced uploads, after the upload is complete MBACCESS will ZIP the upload and re- 48 name the file to the current JOBNUM and then move the file to this full ATTACH path. If you are using an ATTACH link type then the file is left unchanged and moved to the ATTACH path. Normally this field is left blank and a subdirectory ATTACH is used. __ 15___ ________ WELCFILE __________________________ Welcome display file path. __ This is the filename of the welcome screen to be displayed before showing the caller the main menu. You can use this to tell your caller about your on-line database or other information. Notice in the MBPROC.DBF example configuration database that this field is configured as WELCOME with no filename extension. MBACCESS will automatically look for a .SCR ANSI graphics file first to display if the caller has ANSI enabled. If it doesn't find one or if ANSI is disabled, it will then look for a .BBS display file. If the caller supports RIP graphics, it will then look for a .RIP graphic file. This concept of looking for the appropriate display file is used for all display files. Remember, .BBS files can contain ANSI or atcode color codes and MBACCESS will properly strip out color codes if your caller has color disabled. This means only one .BBS is necessary for both color and non-color (monochrome) callers. If you put a filename extension MBACCESS will override this feature and read that file instead. If this field is left blank MBACCESS will look for a WELCOME.xxx file. __ 16___ ________ MENUFILE__ ____________________________ Main menu display file path. Same as 15 above, except will display an alternate main menu screen to your caller. If this file does not exist, a default built-in main menu will be displayed instead. __ 17___ _________ SMENUFILE_ __________________________________ Default profile display file path. Same as 15 above, except will display this file when the caller accesses the DEFAULT USER PROFILE 49 SYSTEM for the very first time! Note: This file is only displayed to the caller ONCE the first time MBACCESS creates a default user profile and MBACCESS will only try to create a default user profile record if any fields are defined as a REPEAT TYPE as explained in the LINKAGE DATABASE SYSTEM in Chapter 7. __________ JOBNUMFILE ___ __ 18 _____ _____________________________________ Job number file containing last Job#. This is the filename of the JOBNUM file used for generating unique JOB numbers for each record. If no filename is used here a default filename JOBNUM will be used. _______ PROCESS _ ____ 19 ________________________ Print Processing toggle. ___ Enables or disables Print Processing. If set to Y, then MBACCESS will print the report format as defined in the PROCESSRPT pathname in field #21 below to the PROCESSOUT pathname as defined in field #20 below. See also Chapter 10, on Print Processing for more details. Note: If you choose yes here, you will have to also create a report format & configure field # 20 and 21 below. __ ___ 20 __________ PROCESSOUT_____ _____ ____________________________ Print Processing out device. This is the full pathname of the file or device to send reports to for Print Processing. Also, if force uploads is in use, each file that is uploaded and attached to a record will add an item to the report output as defined in field #21 below. It will also indicate on the report whether the file was attached successfully or unsuccessfully. This provides additional flexibility by allowing you to put PRN, LPT1, LPT2, etc. so that you can send reports to your printer or specify a filename to send reports to a log file. Using Print Processing a report is printed every time a record is added or updated. Note: 50 A form feed is automatically generated between reports. __ 21___ __________ PROCESSRPT_____ _____ ___________________ Process Report out. This is the full pathname of the file containing the report format for use during Print Processing and when a [T]ext report is generated for [X]fers. The report format is a simple DOS text file that may be edited with any DOS text word processor. Fields are printed using @ CODES. @#003 indicates to MBACCESS that the contents of field #3 should go wherever this is placed in the text file. Regular text is printed verbatim. ________ COMPRESS ___ __ 22 _________________ Compression mode. __ Z - . ZIP using PKZIP L - . LZH using LHA J - . ARJ using ARJ A - ARC using PKARC S - SELECTABLE - Select from one of above. N - No compression used (or leave blank). Note: If field is left blank it disables compression. There is no extra configuration for using compression other than making sure that the appropriate compression programs are in your DOS search path so that MBACCESS can find them. Note: If you are using the select compression method which is very convenient for the advanced caller, you MUST have one of each of the 4 compression programs in your DOS path. ___ __ 23 ________ ERRORLOG ___________________ Error log filename. __ This is the filename of the error log that MBACCESS uses to log errors that may occur during operation. If left blank, an ERROR.LOG file will be created. 51 __ 24___ ________ MBREGNUM __________________________ ModemBase Registration #. __ __ 25___ _________ BADINPUTS _____________________________ Number of bad inputs allowed. _ ________ GRAPHICS ___ __ 26 __ _________________________ Graphics modes available. D - DETECT MODE Will manually detect for ANSI and RIP graphics capabilities without caller intervention. P - PROMPT MODE Same as the DETECT MODE, but if ModemBase detects ANSI and/or RIP graphics it will prompt the caller if he/she wants COLOR or GRAPHICS. B - BBS MODE (RECOMMENDED MODE) This will utilize the MODE as passed via the door information file. Some new DOOR FILES can pass the RIP parameter (like Wildcat) via the DOOR.SYS file. A - FORCE ANSI Will assume the caller has ansi capability and color will be on. N - ANSI NO COLOR Will assume the caller has ansi capability and color will be disabled. R - FORCE RIP Will assume the caller has RIP graphics capabilities and use RIP files if available. T - TEXT MODE Looks for .TXT files NO IBM EXTENDED CHARACTERS, also 7 bit mode. Activated using @NOIBMX@ atcode. ___ ________ XFERMODE __ 27 __ ______________________________ Transfer mode security access. 0 - Disable Transfer Capability 1 - Allow REPORT TEXT transfers ONLY 2 - Allow DATABASE transfers ONLY 3 - Allow FILE ATTACHMENT transfers ONLY 4 - REPORT TEXT and DATABASE transfers OK 5 - REPORT TEXT and FILE ATTACHMENT OK 6 - DATABASE and FILE ATTACHMENT OK 7 - ALL TRANSFERS ALLOWED 52 __ 28___ _______ ADDMODE _______________________________ Record level ADD security mode. ___ The number below indicates the MODE in use. 0) NO ADD ACCESS MODE This mode does not allow the caller to add any records to the database, but does allow the caller to browse or edit records in the database if view or edit access is set below. This mode is useful if you have a database file that you only want callers to be able to view, such as an information database, but you do not want anyone to be able to add any additional data to it. 1) FULL ACCESS ADD MODE This mode allows any caller to add records to the existing database as many times as needed. 2) OWNER ACCESS ADD MODE This mode only allows a single record to be accessed for each caller using the door. There is a check the first time the caller uses MBACCESS and if a record has not yet been added to the database under the callers name, then the caller is allowed to ADD a single record. That record is linked to the callers name which is passed from the BBS via the DOOR.SYS file and further usage of the database will only allow editing of that callers record if editing access has been enabled. A field with a NAME type must be defined and the OWNFIELD in the configuration database must contain this field #. This is how MBACCESS knows which field contains the name of the caller as passed from the BBS door file. ________ EDITMODE ___ __ 29 __ ________________________________ Record level edit security mode. The number below indicates the mode in use. 0) NO EDIT ACCESS MODE 53 This mode simply does not let callers edit any records within the database. 1) FULL EDIT ACCESS MODE This is a very powerful mode and shouldn't be used in secure situations when you don't want your callers accessing other callers records! However, if the need arises to allow callers of a particular database to do this, then this mode will allow callers to access and edit any existing database record. The security level can be set so that only the Sysop has this type of access. 2) OWNER EDIT ACCESS MODE This mode if enabled allows callers to edit their records in the database which they have added to the database. A field with a NAME link type must be defined and the OWNFIELD in the configuration database (field #3) must contain the field # linked to NAME link type. This is how MBACCESS knows which field contains the name of the caller as passed from the BBS door file. ________ VIEWMODE ___ __ 30 ________________________________ Record level view security mode. __ The number below indicates the mode in use. 0) NO VIEW ACCESS MODE No access or ability to view any records. 1) FULL VIEW ACCESS MODE Allows caller to search and view any record in the database. 2) OWNER VIEW ACCESS MODE Allows only the owner of the record to view his/her record(s). A field with a NAME link type must be defined and the OWNFIELD in the configuration database (field 54 #3) must contain the field # linked to NAME link type. This is how MBACCESS knows which field contains the name of the caller as passed from the BBS door file. ________ SYSLEVEL ___ __ 31 __ ______________________________ Sysop security level override. Contains the security level as passed from the DOOR.SYS file of the minimum security level allowed to access the database for Sysop Level Access. Sysop Level Access will allow the Sysop to delete and undelete records from the database as well as override any security level settings at the record or field level. __________ BROWSEMODE __ 32___ _____ ___________________ Browse mode toggle. This toggles browse mode on or off. Y will turn browse mode on (or blank) and N will turn browse mode off. When browse mode is off the caller is always in record view mode. _______ TITLEOK ___ __ 33 ____ Titl ___ _____________________________ e display toggle when adding. When callers add records to your database, MBACCESS displays a built-in title explaining the job number and separator bar. Setting this to N will disable showing the title. ________ APPENDOK ___ __ 34 _________________________________ Allow remote-to-host .DBF append. __ MBACCESS has the ability to allow callers to actually upload a database file in which the records will be appended to the host databases with the same filename that are located in the APPENDPATH as defined in field #35 below. When this feature is enabled the "!" command becomes available on the main menu. __ 35 __________ APPENDPATH ___ _____ ____________________________ Path to append databases to. This is the path that MBACCESS will look for the host database files when using the above field #34 remote-to- host database appending feature. If no path is given, which is actually recommended, MBACCESS will create and use an APPEND subdirectory. 55 __ 36___ ________ POSTPATH ______________________________ Files to be POSTED for ATTACH. __ When using the ATTACH link type and adding files locally, MBACCESS will look in the path given here and show a display of available files for posting as attachments. This feature makes it very easy for Sysops to post many file attachments to databases on a regular basis. If this field is left blank, MBACCESS will create and use a POST subdirectory. __________ PROMPTFILE ___ __ 37 _____ _____________________________ Filename of PROMPTS.BBS file. Most of the prompts within MBACCESS are contained within the PROMPTS.BBS file. Normally, this field is left blank, but if for some reason you need to specify the path and/or filename for a different PROMPTS file, here is where you can do it. ________ FORMFILE ___ __ 38 _________________________________ Filename of record view FORM.BBS. __ ModemBase Pro will always look for a FORM.XXX file to display when the caller is in record view mode, where "XXX" is the extension depending on the callers graphics mode, such as .BBS or .RIP. Normally, this field is left blank, however if you need to specify a different path and/or filename for the record view form, here is where you can do it. ________ HELPFILE ___ __ 39 __ _____________________________ [D]isplay menu help filename. This is the display file that is shown to the caller when the caller selects [D]isplay from the main menu. ________ DISPFILE ___ __ 40 __ ______________________________________ Default Profile display file 1st time. This is the display file that is shown to the caller when using default user profiles. This file is only shown to the caller the very first time the caller generates a new default user profile. __________ SHOWDELETE ___ __ 41 _____ __________________________ Show deleted files toggle. _____ If you want deleted records to be shown to your 56 callers, set this to Y, otherwise set it to N. Deleted records are annotated with an astericks. __________ LOCKRETRYS __ 42___ _____ _____ ________________________ Database sharing retrys. This should not be used at all unless advised by NetConnX technical support department. __________ TWIRLSTRNG ___ __ 43 _____ __________________________ Twirl string display used. _____ This is a cosmetic feature that shows the twirling action when a caller is waiting for processing, like during a search or transfer. You can change the 4 characters used to generate the animated twirl string. __________ PRIMARYIDX ___ __ 44 _____ _____________________________ Primary field used for index. _____ Our goal was to keep the concepts of indexes and their usage simple to use for both the Sysop and caller. We have achieved this by activating the indexing system via this setting alone. Using this primary index field definition, you can select one field in your database as the main field to be indexed (sorted) when first loaded. For example, if you had an on-line database with customer information, you may want to make the customer last name field the primary index field. Then when you go to either record browse or view mode, the data will automatically be sorted by last name. [F]ast index searches can then be performed on the primary index field that are blazing fast and very advantageous if using large on-line databases. Multiple field indexes can be created by setting the fields you want to allow callers to sort by use indexes. This is accomplished via the linkage database as discussed in Chapter 7 for the USEINDEX field. Basically, if the USEINDEX field is set to Y then that field will appear in the dynamic sort list when the caller selects s[O]rt from the command prompt. You will notice that once you select a primary index in the configuration database all the indexing 57 features will automatically activate. When doing a [S]earch you will notice some screens displayed to the caller to explain the search mechanism. This file is displayed as SEARCH.BBS. This file is included to explain to your caller the difference between a [F]ast index search and a [S]low linear search and the advantages and disadvantages of each type of search. Another file called TABLE.BBS is also displayed to explain the differences between a [G]o search and a [T]able search. If these files are removed, then things will still work with just input prompts. You may also change these files to explain things your own way. You will also notice that the browse display will dynamically change to put the field you selected as your primary index or the field the caller s[O]rts by as the first field in the display. Proper field number selection will also change to match the new field layout as well, providing a seamless logical interface change for the caller. _____ _____ 45-58 ________________________ RESERVED FOR RELEASE 2.0 58 Chapter 7 Linkage Database Refer to MBPROL.DBF for an example linkage database. The linkage database file is the key to customizing MBACCESS `` for smart processing. Below is a list of each field '' number in the linkage database. Notice the use of the L ``'' in addition to the MAIN database filename to indicate that this file is a linkage database. Each record # in the linkage database corresponds to the field # in the MAIN database, i.e., Record #1 in MBPROL.DBF corresponds to Field #1 in MBPRO.DBF and tells MBACCESS how to process field #1. Record #2 corresponds to field #2 and so on. Notice there are 23 records in our example MBPROL.DBF file and there are 23 fields in our MBPRO.DBF MAIN database; one linkage Record for each field. [***Figure 7-1 PG 59] 59 ______ Field#____ __________ Field Name __________________________ Description of each field. _____ _ 1____ _________ FIELDNAME ____________________ Enhanced field name. _ Contains the field name you want to display instead of the xBase 10 character limited field name (allows up to 20 characters with spaces). This field is designed to offer a better description than that offered by dBase field names. xBase limits field names to 10 characters with no spaces and doesn't provide much of a description of what the field is. If this field is blank, however, MBACCESS will use the xBase field name instead and display it to the caller. ____ TYPE ____ _ 2 __________ Link type. _____ _ The full name of the link type goes in this field. See MBPROL.DBF or Figure 7-1 for an example of how the TYPES are used. Using the various link types gives MBACCESS specific instructions on how to process the corresponding field. The link types are listed in the following format : LINK TYPE DESCRIPTION NAME Puts name automatically into linked field as retrieved from DOOR.SYS file (or OTHER DOOR TYPES). FROM Puts FROM information automatically into linked field as retrieved from DOOR.SYS file. Note: Different BBS systems pass this information to DOOR.SYS differently. Wildcat! BBS passes the FROM information in the 60 user database, NOT the CITY and STATE information. For information that is not passed to the DOOR.SYS file from the BBS, you can setup fields to be part of the user profile. See Chapter 8 on default user profiles. PHONE1 Retrieves Phone1 information automatically from DOOR.SYS file (or OTHER DOOR TYPES) and puts information into field for caller. PHONE2 Same as PHONE1 above, but PHONE2 info. PID Primary ID is derived from PHONE1 DOOR.SYS data, but only contains numeric data. This is useful for indexing phone numbers and complies with the Telemagic(tm) database PID field format. SID Secondary ID will convert the callers name as passed to MBACCESS via the door information file in the form of LASTFIRST with no spaces. This, like PID above, is useful for indexing names and complies with Telemagic(tm) database SID field format. DATE Puts current DOS date automatically into linked field. TIME Puts current DOS time automatically into linked field. 61 JOB Puts a unique incremental job number automatically into corresponding linked field. MBACCESS reads the job number from JOBNUM or the file pathname as set in the configuration database for JOBNUMPATH. FORCE Requires that the caller DOES NOT leave the input field blank, this will FORCE an input from the caller for the specified field. ATTACH ATTACH allows you to attach files to a field. The field will contain the actual filename of the file. If there is a filename with no pathname, then the ATTACH PATH will be used as defined in the configuration database. If an ATTACH PATH was not defined in the configuration database, then a default subdirectory called ATTACH is created and used. ATTACH link type will also allow remote uploads of file attachments. If you want the attachment to import into a memo (assumes the file is a text file) then put the memo field # in the LINK FIELD #6. Multiple files can be uploaded for file attachments as well. A list of files will be shown to the caller if multiple files are uploaded once the next ATTACH field is reached which can be in the same record or another record. Typing QUIT will allow the caller to not attach a file. When editing ATTACH fields, re-processing will properly occur unless sysop level raw edit is used. Once a file or files is/are attached to a record, the caller may 62 [X]fer attachments if the sysop has enabled this in the configuration database under [X]fer modes. File attachments are a very powerful feature of ModemBase Pro and can be used for a variety of applications. Common uses may be pictures of houses for a real estate database, pictures of people for an actor/actress database, actual resume files for a resume database, and many more uses. If your caller has a graphics terminal communication program such as RIPTERM, FRAC- TERM, DCTERM, QMODEM PRO FOR WINDOWS (AUTOMATIC GIF FILE DISPLAYING), these terminal programs may be used to display graphic pictures that are file attachments. CHOICE Provides a list of choices which are read from another database file as specified in the link configuration file defined under CHOICE DBF and allows callers to select from the list and then will place answer from list into linked database field. The CHOICE type may also be used in conjunction with both the REPEAT types below as well as BRANCH types. CHOICE DATABASES (CHOICE.DBF) If you define a field using the LINKAGE SYSTEM CONTROL FILE as described above as a CHOICE TYPE, then you may use the STANDARD CHOICE RECORD LAYOUT database structure for your CHOICE SELECTIONS. You can run the MBPRO demonstration to see how MBACCESS displays CHOICES to the caller. The available CHOICES are defined in this separate database and over 2 billion choices may be used; however if you plan on using more than 40 choices you should consider using a CHOICE DATABASE with 63 the LOOKUP CHOICEFLD and CHOICEIDX options as described in the LINKAGE SYSTEM CONTROL FILE section. The reason for this is because using the STANDARD CHOICE RECORD LAYOUT, although easier to use, displays all the choices on the screen to the caller. MBACCESS will automatically put your CHOICES into two columns if over 14 CHOICES are available, but anymore than 40-44 CHOICES, (these are actually records in the CHOICE database) MBACCESS will not be able to fit all your choices on the screen and will scroll off the screen. The RECORD LAYOUT of the STANDARD CHOICE database is simple. Below are the fields for each record and their descriptions. CHOICE 1 Here is where the actual CHOICE selection exists. There is one CHOICE per record. Refer to MBPRO.RET to see how we used the MBPRO demonstration and the STANDARD CHOICE RECORD LAYOUT as defined in MBPRO.RET and each CHOICE that is displayed to the caller is pulled from this field. If you want to offer the caller the additional capability to ENTER a CHOICE not found in the selection, i.e. OTHER, then use the keyword OTHER here, and place a prompt description in field 2 below. Your CHOICES maybe up to 30 characters in length in the default CHOICE RECORD LAYOUT. This may be modified, by creating your own CHOICE DATABASE LAYOUT with these same fields, however. 2 DESCRIPTION This field is used if the above field 1 has the keyword OTHER. When MBACCESS sees that you are using an OTHER CHOICE, it will display this description to the caller as one of the list of CHOICES and if the caller selects a field defined with the OTHER keyword, 64 then MBACCESS will also display the description again and prompt the caller to input data. If you want to offer the caller the additional capability to ENTER a CHOICE not found in the selection, i.e. OTHER, then use the keyword OTHER here, and place a prompt description in field 2 below. Your CHOICES maybe up to 30 characters in length in the default CHOICE RECORD LAYOUT. This may be modified, by creating your own CHOICE DATABASE LAYOUT with these same fields, however. Make sure that in your main database field that the CHOICE SELECTED that will be placed into the main database field is at least 30 characters to hold the CHOICE selection or the CHOICE WILL BE TRUNCATED and an error displayed. 3 BRANCH This is a very powerful feature and allows you to decide where MBACCESS will go depending on the callers CHOICE. If you place a NUMBER in this field MBACCESS will go to that field # if the caller selects that CHOICE. If your database is properly planned, MBACCESS can offer endless intelligent responses to your callers selections with this feature. If you leave this field blank, MBACCESS will go to the next field for processing or as determined by the BRANCH field in the LINKAGE CONTROL FILE as described above. NOTE: you are using any CHOICE types, you can also If copy CHOICE.NEW to the CHOICE database filename as configured in Field 4 of the LINKAGE CONTROL FILE or type MBCHOICE <CHOICE DATABASE FILENAME>. TABLE 65 Advanced powerful CHOICE feature. MBACCESS will create a REFERENCE TABLE of any fields STARTING at the field declared as a TABLE TYPE until whatever FIELD as defined in the CHOICEFLD (Field # 5) and will skip CHOICEIDX (Field # 6) number of Fields during processing. Used in conjunction with a CHOICE database as defined in the CHOICEDBF field, MBACCESS will display the x number of TABLE fields with DEFAULT selections as defined in the user profile and DEFAULT SETTINGS. An example where this can be handy is if you had a database that had several fields which are grouped together and in the same database. MBACCESS will generate a cross-reference table on-line allowing the caller the ability to make permanent or temporary changes to the user profile for items that are part of the TABLE. Any database items that can be grouped together as a SUBJECT, can be used in a TABLE. For instance, you might want to group together a CALLERS BILLING ADDRESS information. This information would be defined in his or her DEFAULT USER PROFILE. There may be five separated fields in the database that are used in the RECORD LAYOUT for this. These fields can be grouped easily by defining the first field in the group as the TABLE field. Then you also tell it the number of fields consecutively that are in the group (CHOICEFLD) and you're all set. MBACCESS knows how to handle the rest. When the caller is being processed on-line MBACCESS will display a TABLE of the fields in your group. The caller can PRESS [ENTER] to accept the DEFAULT SETTINGS for each field in the group as it is defined in his or her USER PROFILE, or select any one of the fields in the group to CHANGE temporarily for just the immediate record being added to the database, or even permanently have the option to make the new selection recorded in the DEFAULT 66 USER PROFILE. DEFAULT Will retrieve corresponding field data from the default user profile database record defined as `` DEFAULT SETTINGS '' in the OWNER field (See configuration database on OWNFIELD). The default data retrieved will then be AUTOMATICALLY inputted and IS NOT CONFIGURABLE by the caller! Important Note! If you want to use default user profile information that the caller can configure, you need to use the REPEAT OPTIONS as outlined below. Using this DEFAULT link type can allow you to automatically insert specific information into a database field, i.e.; a Store Location Number. DEFAULT LINK TYPES The following formats are handled directly by your database configuration and are specific to xBase compatibility : Character Field C Numeric field, # of Decimal Places N Date Field D Logical - True or False/Yes or No L Memo - Attached file (up to 64K) M These field type characteristics are automatically handled by MBACCESS during user input and internal to database format. Each of these DEFAULT TYPES also have a defined LENGTH. Memo fields are the exception. Memo fields are 10 characters in length and the MEMO Field itself only holds a record number of the actual memo contained in the corresponding XXXXXXXX.DBT memo file where XXXXXXXX `` is '' the 67 name of the database file. Memos are variable length fields and can be UP TO 65,535 characters. ________ TEMPLATE _ 3____ Reserved for release 2.0. ______________ REPEAT OPTIONS _ 4____ You can put a '' S `` for SAVED INFORMATION REPEAT, or an `` O'' for OPTIONAL INFORMATION REPEAT, or a for DEFAULT '' D `` REPEAT. (See DEFAULT SETTINGS `` for more info.) REPEAT '' OPTIONS may be used in conjunction with TYPES above, even CHOICES. Any field defined as a REPEAT OPTION will generate a DEFAULT USER PROFILE in the SAVED INFORMATION DATABASE. See MBPROS.DBF for an example of the SAVED INFORMATION DATABASE. This database is a duplicate of the MAIN DATABASE RECORD LAYOUT, but keeps DEFAULT USER PROFILE INFORMATION of any field with a REPEAT OPTION defined and saves the information for future sessions. This also helps maintain a customizable CUSTOMER database or other information which may be repetitive and is often needed as explained in CHAPTER 2 DATABASE PRIMER. OPTIONAL - O Allows reference to a default USER PROFILE record in the SAVED INFORMATION DATABASE. OPTIONAL REPEAT is configured in the LINK DATABASE for each field and _______________ may be used in _________________________ conjunction with ANY LINK types, including CHOICE types. As MBACCESS processes a record in your database for input by the caller and as it encounters a field defined as an OPTIONAL REPEAT type, MBACCESS will look up the callers DEFAULT USER PROFILE in the SAVED INFORMATION DATABASE. (Note: MBACCESS will ask the 68 caller to configure his/her DEFAULT USER PROFILE upon the first time [A]dding a record to the database, prior to processing the database, and only if a REPEAT type has been configured.) MBACCESS will retrieve the DEFAULT information for the REPEAT field being processed at the time and since it is an ``Optional Repeat, the caller is displayed the '' DEFAULT information, but is also given the opportunity to either hit [ENTER] and accept the DEFAULT information or edit the DEFAULT information displayed in the INPUT FIELD. If the field is defined as a CHOICE type and an OPTIONAL REPEAT type, then the list of CHOICES will be displayed along with the DEFAULT CHOICE as configured in the DEFAULT USER PROFILE and the caller may either hit [ENTER] for the DEFAULT CHOICE or select one of the available CHOICES from the list. SAVED - S This REPEAT type is similar to OPTIONAL REPEAT type in most aspects, except that it DOES NOT allow the caller to EDIT the REPEAT information retrieved from the DEFAULT USER PROFILE. SAVED REPEAT will simply automatically place the default information into the field being processed and move on to process the next field. DEFAULT - D This will override the callers default user profile setting and pull up the value if one exists contained in the ``DEFAULT SETTINGS record within the default user profile '' database. It is important to note that this is usually only needed in conjunction with CHOICE types, otherwise a DEFAULT TYPE should be used. When used with CHOICE TYPES it overrides the callers DEFAULT CHOICE with that as defined in ``DE the 69 FAULT SETTINGS'' record. See DEFAULT TYPE for more information on the DEFAULT SETTINGS `` '' record and it's usage. _______ LINKDBF ____ _ 5 This is the filename of the separate CHOICE database which is a separate xBase compatible database containing the list of CHOICES available for input. Field 2 MUST CONTAIN the CHOICE type in order for MBACCESS to look for a CHOICE database. See MBPRO database MBPRO.RET for an example of the record layout of a STANDARD CHOICE DBF. Run MBPRO example to see how MBPRO handles CHOICES on-line. If you want to use a DATABASE that does NOT use the STANDARD CHOICE DATABASE RECORD LAYOUT, then see 6-7 below. This can be useful for using separate databases as a LOOKUP `` for a '' CHOICE SELECTION. You may use a full file PATHNAME here also. __ ___ 6-7 ___________________ LINKFLD AND LINKIDX Used with GROUP and TABLE link types. _ 8 ___________ BRANCH NEXT ____ Field to branch to next. If left blank branches to next field in database by default. ____ _____________________________ DOES THIS FIELD USE AN INDEX? _ 9 If you set this field to Y, MBACCESS will generate and index file automatically for the corresponding field. The caller will then be able to use the s[O]rt command and any fields set to Y to use and index will appear in the sort list. The caller can arbitrarily s[O]rt by which ever field they want. See the explanation also on primary index in Chapter 6 configuration database. ___ ______________ INDEX FILENAME __ 10 This is the optional filename to be used for the index 70 file. If it is left blank, an index filename will be generated with the first 8 characters of the xBase corresponding field name. _______________ EVALUATION MODE ___ __ 11 Planned for Version 2.0 - Will allow fields to be processed before or after input with evaluation commands and allow full programming. ________ SECLEVEL ___ __ 12 This is the minimum SECURITY LEVEL as passed from the DOOR file to access this field. If the field is BLANK, SECURITY LEVEL check for corresponding field is DISABLED. _____ _____ 13-16 _____________________ FIELD SECURITY LEVELS Set the level required for each type of access, add, edit, view, and xfer per field. [This page blank] 71 Chapter 8 Default User Profile This database is simply a duplicate of your MAIN database record layout, but is used to hold repetitive field information such as a default user profile. MBACCESS will search this database by the owner field as configured in the configuration database (see Chapter 6 - Configuration Database on OWNFIELD) and will use this file for any field defined with a repeat option or a DEFAULT link type. If DEFAULT link type is used in the linkage database then MBACCESS will look for an record with the words DEFAULT `` SETTINGS'' in the OWNFIELD rather than the name of the caller as passed from the BBS. See also MBPROS.DBF (\MBPRO\DEMO\MBPRO\) for an example. Using the default user profile can be very advantageous if your caller will be adding records to your database more than once. The first time a caller [A]dds a record to the database, MBACCESS processes the caller to see if a default user profile exists in the saved information database for that caller. If one does exist and there are fields in the MAIN database defined as either a repeat option or DEFAULT link type, then MBACCESS will pull up the existing user profile. If one does not exist then MBACCESS will ask the caller to setup his/her default user profile. The file as defined in the configuration database for SMENUPATH will be displayed prior to entering the default user profile setup the first time. See also Chapter 5 - Overview of files and databases for files that are associated with editing of the default user profile, such as ENDUSER1 and ENSUSER files. 72 If you use the default user profile system, make sure your MAIN database contains a field with the caller's name and it is suggested that you use NAME link type in the linkage database for that field so that MBACCESS will always automatically pull the caller's name from the door information file and will remain constant. Also be sure to configure the OWNFIELD in the configuration database to indicate what the field number of the callers name is. MBACCESS will automatically handle the rest. The caller can reconfigure his/her USER PROFILE at any time from the main MBACCESS menu ([I]nformation). The default user profile can be used for many applications. It can generate a customer record of information that is not available as passed from the BBS in the door information file, such as billing address. Using the default user profile can ease data entry for your callers. 73 Chapter 9 The on-line interface Let's assume for a moment that you wanted to put a database on-line and ModemBase Pro or a product like it did not exist. At first glance, the concept may seem fairly easy and straightforward. You need to provide a method for your caller to be able to browse and view records and navigate the database. A traditional database application may have a pull-down menu system or other menu system. The problem with traditional database applications is that they are NOT written for the on-line world. When dealing with an on-line caller, you must also consider the limitations of the terminal communication program that the caller is using to access your database. ModemBase Pro has taken a unique approach to solving many of the problems inherent to on-line communications. The on-line interface mechanism for Modem Base Pro has been carefully designed to allow virtually any type of caller ranging from TEXT and ANSI to RIP graphics. ModemBase Pro has been purposely designed to prevent having to force your caller to access your database with a specific communication program. Because of this, commands such as [N]ext and [P]revious are used instead of traditional commands like PGUP and PGDN key. Most communication programs reserve function keys and cursor movement keys and they do not properly translate or transmit the keyboard codes for those keys. With this in mind, ModemBase Pro uses navigation commands that will work for virtually all types of callers. ModemBase Pro relieves you from the responsibility of creating an entire on-line interface and application. You simply have to 74 create a database file or use an existing one. You can literally take a database file and after setting up with COMPOSER, your database is on-line in under 10-15 minutes with a robust and easy-to-use interface that is also very powerful. You can then customize the interface screens to display data the way you want or let ModemBase Pro do the work for you and use the built-in dynamic displays. Extensive care has been taken to design an interface that your caller will find intuitive and [***Figure 9-1 PG 76] require a minimal learning curve. There are basically two ways in which a caller can view your database on-line. A Browse Mode exists which allows the caller to browse several records at a time on a screen. Figure 9-1 shows an example browse screen. The top line of the browse screen shows that the caller is in Browse Mode, the name of the current database (TELFON.DBF in this case), and [ENTER] = VIEW. The [ENTER] key (or [RETURN] key on some keyboards) will toggle between Browse Mode and Record View/Edit Mode. Below the title is a dynamic display of the field names. [+] and [-] may be pressed to scroll the 75 [***Figure 9-2 PG 77] data right and left while on-line. [P]rev and [N]ext indicators appear and will allow the caller to essentially page up and page down through records. The first column contains the actual record number of the data. If s[O]rt is pressed a dynamic list of fields which can be sorted is displayed as shown in Figure 9-2. Remember, using the linkage database is where you tell MBACCESS which fields can be used for sorting. This database example has two fields configured for sorting. The primary index field was set to LAST NAME and if you [***Figure 9-3 PG 77] 76 wanted to change the current sort to FIRST NAME, you would select item 3 in the sort selection list. The browse display will then dynamically change to show the new sorted field as shown in Figure 9-3. Below the data display is the currently sorted field and notice that the first column of data is sorted by last name. Notice in Figure 9-3 compared to Figure 9-1 that the current top record was Ralph Martinez and remained the current record even after a new field to s[O]rt by was selected. Also notice how the browse display dynamically changed and now the FIRST NAME field is displayed as the first data field. [***Figure 9-4 PG 78] If you wanted to look at the Ralph Martinez record in detail, the other way to view data on-line is the Record View/Edit mode. Pressing [ENTER] will toggle between the Browse Mode and the Record View/Edit Mode. Figure 9-4 shows the Record View/Edit mode after pressing [ENTER]. You could have also toggled between Browse Mode and Record View/Edit mode by typing the actual record number of the item in the browse list. In this case, if you 77 had typed 67 you would have gotten the same results as pressing [ENTER]. You could have also hit [V]iew and notice now that Record View/Edit mode is active a [B]rowse command appears on the command prompt line. Pressing [B]rowse will go back to Browse Mode. Figure 9-4 shows a detailed view of the record. While in Record View/Edit mode, pressing [P]rev and [N]ext will allow the caller to traverse through the records in the database one at a time. If there are more fields than can be displayed on a single screen, then you can use [+] and [-] to page up and page down through fields. Below is a list of each of the commands available while on- line and their function : Edit [#] When in browse mode, typing the record number will take you to the record and display it in record view/edit mode. If in record view/edit mode, typing the field number will allow the field to be edited assuming the caller has edit access to the record and field. If the field being edited has a link type defined for it, then the field will be reprocessed using the link type. If the caller has sysop level or greater access, MBACCESS will ask and allow you to either raw edit the field or reprocess it with the link type. If no link type has been defined for the field in the linkage database, then the field will be edited normally. [G]o Will allow you to change the current field. [+] When in browse mode will scroll data from right to left. When in record view/edit mode will scroll data down 78 a page assuming there is more fields than fit on the screen. [-] When in browse mode will scroll data from left to right. When in record view/edit mode will page up data if already paged down using [+]. [N]ext When in browse mode will page down records assuming there are more records in the database than what can be shown on the screen. The [N]ext command will only appear when there are more records to view. When in record view/edit mode will go to the next logical record in the database depending on the currently sorted field. [P]rev When in browse mode will page up records assuming there are more records to page up to. The [P]rev command will only appear when there are more records to view. When in record view/edit mode will go the previous logical record in the database depending on the sorted field. [D]el/Undel If the caller has Sysop level access or higher this command will appear and allow the caller to delete or undelete records in the database. [X]fer This allows the caller to transfer reports or actual databases and file attachments via one of the following Xmodem, Ymodem, or Zmodem file transfer protocols. See ATTACH link type for use with file attachment. Also 79 refer to Chapter 6 field 27 in the configuration database for details on the various transfer modes available. Custom [T]ext reports can be designed by defining a report format file. This is also explained in Chapter 6 under field 31 PROCESSRPT (Process report out). If a custom text report is not defined, MBACCESS will generate a dynamic report. [A]dd This option allows the caller to add records to the database assuming the caller has been granted add security access as discussed in Chapter 4. ModemBase Pro offers powerful information gathering features to enhance on-line data entry. It is encouraged that you take the time to go through each on-line demonstration database and add some records to see the various features available to you for use in your own database designs. You can also look at each of the demonstration linkage databases for the actual configuration. See also Chapter 10 advanced concepts under Add Record Logic for more information on what specifically happens when a record is added to the database. [H]elp This will display the HELP.BBS file to the caller explaining each of the commands. You may edit this file to be more specific about your particular database design. [S]earch One of the most powerful features offered in ModemBase Pro is its search capabilities. Callers may search the database for a keyword. All found records are then presented to the caller. When a [S]earch is performed, MBACCESS first asks the caller for the 80 [***Figure 9-5 PG 82] search keyword. In Figure 9-5 we are searching for the keyword "martinez". If a current sort is active, then the ability to do a [F]ast or [S]low search is allowed. MBACCESS displays the SEARCH.BBS file to explain the difference between a [F]ast or [S]low search. If no indexes are being used or if the caller is sorting by record number, this step is skipped and a [S]low search is automatically selected since [F]ast searches can only be performed on the currently sorted field. Refer to [***Figure 9-6 PG 82] 81 [***Figure Figure 9-6a] You may edit the SEARCH.BBS display screen to explain the difference in your own words. Next, you are asked if you want to perform a [G]o search or a [T]able search. Refer to Figure 9-6. The display file TABLE.BBS is shown to help explain the difference between each type of search. A [T]able search is very powerful when dealing with large databases. All found records are placed into a separate browse table. A [G]o search will go to each match found and remain in a [***Figure 9-7 PG 83] 82 search mode. The advantage of a [T]able search is the ability to create multiple search tables and [R]everse and [F]orward between each search table. Refer to Figure 9-7. You can then telescope your Search. Figure 9-7 shows that two matches were found and placed into a separate browse table. Notice the [R]ev command that appeared at the top right of the screen. [R]ev and [F]wd commands appear when performing multiple table searches to allow you to navigate between each table. You can re-search tables to effectively perform advanced boolean type searches logically. This is called a telescopic search. Additional table searches narrow down the data set to exactly the information you are looking for. Once a search table contains the data you need, you can then [X]fer a report of the information within a table or edit the data assuming edit security access is allowed. A [G]o search is also very powerful, but differs from a [T]able search. A go search will find each match and stop along the way to allow you to view or edit the found match, but remain in a go search mode as shown in 83 Figure 9-8. Go search mode can be handy for editing records or looking for specific field matches. A go search actually stops at each record and field for each match. A table search pulls the whole record into a separate table on any matches. Either search mode gives you the ability to perform powerful searches and find the exact data you are looking for. [J]ump Jump direct to any record in the database and make it the current record. [E]dit Allows complete re-editing of the entire record. Edit will also allow you to specify a starting and ending field, so that you can edit a range of fields. Only fields that the caller has security access to will be allowed to edit. Sysop security level or higher can edit all fields. [L]ines Allows the caller to change the number of lines displayed on the screen. This can also be set via an atcode @LL=#@. See Chapter 10 on atcodes. [V]iew or [B]rowse Will toggle between record view/edit and browse mode. Same as pressing [ENTER]. s[O]rt Allows a field to be selected for sorting. [F]ast searches can be performed on the currently sorted field. [Q]uit Quits either table or go search mode or quits 84 MBACCESS. Hidden commands. If you have sysop level access or greater, pressing an astericks [*] allow you to re-import a memo field. MBACCESS MAIN MENU Before your caller can even browse a database a main menu is displayed. The main menu has the following possible options : [A]dd records to database [B]rowse/View/Edit/Search Database [I]nformation on default user profile. [D]isplay information (displays DISPLAY.DOC) [G]o back to menu (if using loadmenu) [H]ang Up [Q]uit back to BBS [!] Remote to Host database append (only available if APPENDOK is set to Y) The main menu commands are fixed and can not be changed, however the ability to change the commands is on the development list for a future release. You can create your own MAINMENU.BBS file that is displayed to the caller. If the caller does not have security access, certain commands will not be allowed. MBACCESS WELCOME MENU A welcome menu is displayed before the main menu if one is found. The default welcome menu filename is called WELCOME.BBS. This filename may be changed via the configuration database. 85 Chapter 10 Advanced Concepts This chapter explains some of the more advanced features of ModemBase Pro and their usage. Transfer System using [X]fer command All transfers require an external file transfer protocol. For serial ports, MBACCESS looks for DSZ.COM or DSZ.EXE. If you are using digiboards or fossil drivers you will need to obtain the XFERKIT.ZIP file from the ModemBase Pro technical support conference #2 file area on NetConnX BBS at 909-699-2212. XFERKIT.ZIP contains step-by-step instructions on how to transfer using fossil drivers. (Digiboard owners requires the use of DigiFossil which is also included in the XFERKIT.ZIP file.) Record View FORMS. When the caller is viewing a database record in [***Figures 10-1 PG 87] 86 record view/edit mode MBACCESS looks for a FORM.BBS file. The form is a very powerful feature of ModemBase Pro, which allows you to design custom data display screens and present your data exactly the way you want to your caller. Refer to Figure 10-1. The order database demo FORM.BBS gives you an idea on how to generate WYSIWYG (What You See Is What You Get) forms. It's important to notice the @IF1@ atcode which enables the intelligent form feature. You can use any text or ANSI editor to generate forms. The form in Figure 10-1 was generated using Wildcat's WCDRAW by Mustang Software which comes standard with Wildcat BBS. TheDraw by TheSoft Programming is also very popular ANSI drawing program. At any rate, refer to the next section for a list of available atcodes allowed in FORMS. ATCODES An atcode is a keyword surrounded by "@" (at) symbols. When MBACCESS is displaying a file or a form, it interpets these atcodes as instructions. There are atcodes available to change screen colors and atcodes to display field data as well as a few others. There are full atcode names and sometimes an alternate abbreviated 3 letter atcode name. Abbreviated atcodes are provided to help provide smaller atcode commands which is handy when creating intelligent forms. Below is a list of ALL atcodes currently supported within a display file or form. All atcodes require an @ ``'' symbol before and after the code. _______ ATCODES___ _____ ___________ DESCRIPTION @REC@ Displays current record number @LNAME#@ @LNM#@ Displays Linkage Field Name for field # @DNAME#@ 87 @DNM#@ Displays xBase field name for field # @FLD#@ Displays data for field # for current record @SMODE@ @SMD@ Displays either ON or OFF for GO SEARCH MODE @TOTALRECS@ Displays Total Records (Right Justi fied) @TOTALRECR@ Displays Total Records (Right Justi fied) @TOTALRECL@ Displays Total Records (Left Justified) @SEARCHKEY@ @SKY@ Displays current table search keyword @MENULEVEL@ @MNL@ Displays current load menu level @MAXLEVEL@ @MXL@ Displays maximum table level in use @SLEVEL@ @SLV@ Displays current table search level active @DBFNAME@ @DBN@ Displays main database filename @DESCRIPT@ @DSC@ Displays short description from configuration database @TABLEFILE@ @TBF@ Displays the filename of the current search table Note : The above atcodes support Intelligent Form Processing (@IFORMON@ or @IF1@) and will properly display the data and compensate for variable size of data within the form. If Intelligent Form Processing is disabled (@IFORMOFF@ by default) then changing data sizes will not be compensated for within the display form. For simple forms @IFORMOFF@ is probably sufficient, but if data is required to be aligned and formatted properly, @IFORMON@ will be necessary. The atcodes below offer control over various modes and functions. @ATON@ Turns on ATCODE processing (default on) @ATOFF@ Turns off ATCODE processing @PROMPTON@ @PR1@ Turns Record View PROMPT ON @PROMPTOFF@ @PR0@ Turns Record View PROMPT OFF @BROWSEON@ Turns on Browse View Record Mode @BROWSEOFF@ Turns off Browse View Record Mode 88 @BROWSETOG@ Toggles Browse View Record Mode @IFORMON@ @IF1@ Turns ON Intelligent Form Processing @IFORMOFF@ @IF0@ Turns OFF Intelligent Form Processing @CLS@ Clears both LOCAL and REMOTE screens @TAB=#@ Sets TAB character conversion size. (DEFAULT=8) @LL=#@ Sets LINE LIMIT for dynamic displays @FN=FILE.EXT@ Displays another FILE (FILE.EXT) Full Paths are OK. @MEMO=#@ Sets the # of QUICK VIEW memo lines. @PAUSE@ Displays a pause prompt to the caller @NEWLINE@ @NWL@ Sends a carriage return and line feed @TITLEON@ Turns Title Bar on when adding records @TITLEOFF@ Turns Title Bar off when adding records @COLORON@ Turns ANSI COLOR on @COLOROFF@ Turns ANSI COLOR off @COLORTOG@ TOGGLES ANSI COLOR @RIPON@ Turns RIP GRAPHICS mode ON @RIPOFF@ Turns RIP GRAPHICS mode OFF @RIPTOG@ TOGGLES RIP GRAPHICS mode @APPENDON@ Turns on APPEND command on main menu : `!' = APPEND @APPENDOFF@ Turns off APPEND command (default off) NOTE : When using ANSI editors DO NOT limit the line length or you may have unpredictable results as this tends to put ANSI codes in the middle of atcodes embedded in your form design. If this happens MBACCESS cannot interpet the atcode properly and the atcode will appear when displayed. 89 Color Code chart for @BF@ color codes : _________________ BACKGROUND MODES: _____ ____ _ B _____ COLOR_____ _________ ATTRIBUTE 0 Black NORMAL 1 Blue NORMAL 2 Green NORMAL 3 Cyan NORMAL 4 Red NORMAL 5 Magenta NORMAL 6 Brown NORMAL 7 White NORMAL 8 Black BLINKS FOREGROUND 9 Blue BLINKS FOREGROUND A Green BLINKS FOREGROUND B Cyan BLINKS FOREGROUND C Red BLINKS FOREGROUND D Magenta BLINKS FOREGROUND E Brown BLINKS FOREGROUND F White BLINKS FOREGROUND _________________ FOREGROUND MODES: _ F _____ ____ _____ COLOR_____ _________ ATTRIBUTE 0 Black NORMAL 1 Blue NORMAL 2 Green NORMAL 3 Cyan NORMAL 4 Red NORMAL 5 Magenta NORMAL 6 Brown NORMAL 7 White NORMAL 9 Blue HIGH INTENSITY (BRIGHT) 8 Black HIGH INTENSITY (BRIGHT) A Green HIGH INTENSITY (BRIGHT) B Cyan HIGH INTENSITY (BRIGHT) C Red HIGH INTENSITY (BRIGHT) D Magenta HIGH INTENSITY (BRIGHT) E Brown HIGH INTENSITY (BRIGHT) F White HIGH INTENSITY (BRIGHT) Use in display files for color codes with @BF@. 90 Enhanced memo link types for processing MBACCESS can process memo fields per your instructions by using memo link types in the linkage database for the corresponding memo field. _______________ MEMO LINK TYPES_____ ____________ DESCRIPTIONS LMEMO LINE EDITOR (TEXT ONLY CALLERS OK) FMEMO FULL SCREEN EDITOR (ANSI REQUIRED) AMEMO WILL ASK CALLER FOR WHICH EDITOR TO USE. LMEMOI LINE EDITOR OR ALLOW UPLOAD TEXT FILE IMPORT FMEMOI FULL EDITOR OR ALLOW UPLOAD TEXT FILE IMPORT AMEMOI WILL ASK CALLER AND ALLOW UPLOAD IMPORT. If no link type is given for a memo field, then MBACCESS will default to LMEMO (which is compatible with previous versions). Sysop level access ALWAYS DEFAULTS to AMEMOI mode, regardless of memo link type setting used. 91 Print Processing If enabled via the configuration database, print processing occurs each time a record is added to the database. At this time there is no advanced information on print processing. Refer back to Chapter 6 - Configuration database. Add Record Logic MBACCESS follows specific LOGIC FLOW and rules consistently when [A]dding records to a database. This LOGIC is what gives you the power to create intelligence when MBACCESS is processing your databases. The internal logic involved when adding a record to the database is actually quite complicated, but we have detailed hard fast rules for various situations and knowing these rules will help you with your database designs. Knowing how ModemBase processes a database can help you exploit its many features. The add record logic can handle four different operations. When a caller [A]dds a record to the database, one of these four operations take place. The add record logic is used when adding a new user profile record to the user profile database, editing an existing user profile using [I]nformation on default user profile from the main menu, adding a record to the main database when choosing [A]dd record from the main menu, or when [E]diting an existing record from the Browse/View/Edit command line prompt. Any of these 4 modes initiate the add record logic and the logic is required since each of these modes handle data processing differently. MBACCESS Add/Edit Record Logic Flow and RULES : 1. Security Check. If you are using an OWNER 92 ADD ACCESS MODE then ModemBase will first check to see if the caller already has a record in the main database file. If the caller does already have a record the caller is displayed a message indicating there is already a record in the database and returns him to the main menu. 2. Repeat options check. If the caller has access then ModemBase checks to see if the caller has setup a default user profile, but only if there are fields in the main database that have been defined with repeat options (explained in Chapter 7 - Linkage database) of [O]ptional or [S]aved. Remember, any fields defined with repeat options will allow the caller to enter the data into the field for convenient OPTIONAL or SAVED retrieval when adding records. If the caller has not setup his or her defaults for any defined repeat option fields, then the caller is immediately first asked for the default information for each field defined with a repeat option of O or S. ModemBase actually recursively calls this add logic again to process the default user profile database in a special mode which only asks for fields defined with repeat options. If the default user profile has already been set, or one is not required, or the caller sets one up at this point, then ModemBase Pro will continue on allowing the caller to add (or edit) a record to the main database. Repeat Options used in conjunction with link types will be described shortly. 3. Field Processing Begins. ModemBase systematically processes each field sequentially in your main database when gathering information (programmed field branching is allowed). As it gets to each field it uses the linkage database to see if there is any specific instructions that need to be performed for the current field. The ultimate goal is to put data into the field or 93 direct process to another field and repeat the field processing all over until the last field in the database is reached. There are several different ways of putting data into a field such as, letting your caller type it in, displaying a list of choices for your caller to select from using CHOICE, TABLE, or GROUP link types, or retrieve data from other information sources such as the DOOR INFORMATION file, TIME, DATE, DEFAULT SETTINGS, or DEFAULT USER PROFILE. Each method gives you and your callers different ways of gathering information and ultimately putting that gathered data into the current field. Below is an overview of the FIELD PROCESSING LOGIC and RULES : A. If linked field is defined as a SKIP link type then ModemBase will go to the next field or if a branch field is defined within the linkage database along with the SKIP link type, ModemBase will go to the branched field as defined. B. If a field being processed is from a previous branch, the current field will change to the specified branch field. Branch fields may be defined in either the linkage database or even choice databases. When using branch fields in your choice databases, you can give your database decision making ability by branching to certain fields for processing based on choices selected by the caller. C. Reset Variables and Flags. As each field is processed, ModemBase relies on certain internal variables and flags so that it can track activities and modes when in other processes, such as CHOICE, TABLE, and GROUP link types. These variables are reset to default values before each field is processed. This way if nothing is defined in the linkage database, ModemBase 94 will still process the field, simply gathering information from the caller using the xBase field name as a field description and conforming the callers input to match the xBase field type, i.e. character, numeric, date, logical, memo. D. Check to see if field can be accessed by the caller. FLDOFF evaluation command or field security levels as defined in the linkage database may be used to control access to field data. If the field is defined to not be displayed and the caller does not have Sysop or better security level (defined in configuration database), Modem Base will not display any information about the field, but it is important to realize that the field will still be processed for any AUTO UPDATE link types or any fields that have DEFAULT USER PROFILE DATA (also known as REPEAT OPTION FIELDS) (Remember, an AUTO UPDATE link type is any link type that automatically stuffs the data into the current field being processed, such as NAME, PHONE, DATE). The FLDOFF evaluation option (this is the only place the use of FLDOFF is documented) is often useful when you want to process a field such as a TIME link type for example, but you do not want that information displayed to the caller during processing or allow the caller to edit the field data. E. Check to see if a REPEAT OPTION is used for the current field. This check involves a considerable amount of logic processing depending on which of the 4 add/edit modes are being used. (Remember, the add mode implies 4 different modes of operation when processing a database record as explained previously in the introduction paragraph.) Below is a chart for the different add modes and how each operates in each mode: 95 ____________________________________________________________ CHART OF 4 MODES OF OPERATION FOR REPEAT OPTIONS DURING _______________ FIELD ADD/EDIT. REPEAT : Adding a new user : Editing existing user : Adding/Editing a record OPTION : profile record : user profile via [I]nfo : to/in main database file ------------------------------------------------------------ ------------------------------------------------------------ --------------- Optional : Read and Display : Read and Display : Allows editing of field : data if found in : data if found in : data for inputting or : DEFAULT SETTINGS : default user profile : can hit enter to accept : for current field. : for current field. : DEFAULT USER field info. ------------------------------------------------------------ ------------------------------------------------------------ --------------- Saved : Read and Display : Read and Display : Will NOT allow callers : data if found in : data if found in : to edit or input when : DEFAULT SETTINGS : default user profile : adding/editing record. : for current field. : for current field. : Must use [I]NFO to edit. ------------------------------------------------------------ ------------------------------------------------------------ --------------- Default : NOT PROCESSED : NOT PROCESSED : Will pull DEFAULT : : : SETTING field data for : editing or can hit : : : enter to accept info. (Note: Add/Edit is considered two separate modes, but are grouped together in the chart below.) Special Notes : These repeat options follow the same rules when used with GATHER, CHOICE, TABLE, and GROUP link types. Repeat Options will also function properly on fields with 96 field display turned off, but WILL NOT allow the caller to edit the data as in [O]ptional Repeat. F. Next, any link types will be processed according to their respective function. GATHER link type (or if no link type has been defined) will simply gather information from the caller. Other link types are meant to either retrieve information automatically and stuff it into the field for the caller or allow the caller to choice from a list of selections using CHOICE, TABLE, or GROUP link types. G. The field processing repeats itself continuing to the next field (or branched field) until all fields have been processed. 4. Record is processed and completed. Once all fields have been processed, the field data is then either added to a new record in the database or will update an existing record in the database. Depending of which of the 4 add modes is being used, Modem 97 Base will save the record information differently. Here is a table of the 4 modes and how the record is saved : ________________________ ADD MODES _____ _ _____________________ DESCRIPTION OF RESULT ------------------------------------------------------------ ------------------------------------------------------------ -------------------- ADD NEW USER PROFILE Adds a NEW RECORD to the DEFAULT USER PROFILE RECORD database with the callers name in the specified OWNER FIELD as defined in the configuration. ------------------------------------------------------------ ------------------------------------------------------------ -------------------- EDIT EXISTING USER Using the [I]nformation on DEFAULT USER PROFILE PROFILE RECORD command from the ModemBase Pro Main Menu, a caller can edit his/her DEFAULT USER PROFILE. The DEFAULT USER PROFILE database is a duplicate record layout of the main database, however it contains default field information. Callers are matched to an OWNER FIELD for their specific DEFAULT INFORMATION. Only fields defined with a REPEAT OPTION will be used with a DEFAULT USER PROFILE. ------------------------------------------------------------ ------------------------------------------------------------ -------------------- ADD NEW RECORD TO Will add the new record to the database. MAIN DATABASE Each Field in the record is processed according to the FIELD PROCESSING rules listed previously and if the caller is allowed to add more than one record to the database, he/she will be prompted to add more records to the database. ------------------------------------------------------------ ------------------------------------------------------------ -------------------- EDIT EXISTING RECORD This command will reprocess an entire existing IN MAIN DATABASE record in the database using the BROWSE/RECORD VIEW/EDIT command line option [E]dit. The 98 database will be processed normally using the FIELD PROCESSING rules listed previously, but will update the existing record in the database with the new data. ------------------------------------------------------------ ------------------------------------------------------------ -------------------- Special Notes : At any input field a caller may type QUIT alone and the record will not be added or updated. When using CHOICE link types a [Q]uit option is also available to the caller. OVERVIEW of the ADD/EDIT DATABASE RECORD LOGIC FLOW AND RULES : ModemBase Pro uses a considerable amount of logic when processing a database. This logic and the associated rules are what provide ModemBase with its ability to add intelligence to your database processing. You instruct ModemBase Pro how to process each field in a record when gathering information by defining associated linkage records in the linkage database. The linkage database contains records, where each record corresponds to a field in the main database. 99 Record #1 in the linkage database corresponds to field #1 in the main database, record #2 corresponds to field #2, and so on... Using repeat options, link types, and other available features found in the linkage database record, you can add intelligence to your database record/field processing without having to be a database developer or programmer. Some may feel that we have provided you with too much information pertaining to the logic flow of the system, but we believe that IF YOU KNOW THE RULES, YOU WILL DESIGN BETTER DATABASE APPLICATIONS. 100 This page is intentionally blank. 101 Index Symbols %WCNODEID% 24 .DBT memo file 33 .PRG programming 4 91 @BF@ A ACTIVITY.DBF 39 31 Add ADD MODE 53 Add Record Logic Flow and Rules 93 Advanced Concepts 87 29 ALT-N 29 ALT-X 92 AMEMO AMEMOI 92 42 ANSI ANSI color graphics file 41 ANSI NO COLOR 52 APPENDOK 55 APPENDPATH 55 51 ARC 51 ARJ ATTACH 48, 56 49, ATTACHPATH 48 autonode 25 B BADINPUTS 52 BBS MODE 52 BBS TYPE 46 27, BEEPTIME 46 Browse Mode 76 Browse Table 83 BROWSEMODE 55 102 C CALLINFO.BBS 27 CATEGORIES 31 CHAIN.TXT 27 CHANGES.DOC 25 Chapter 1 - MBPRO CONCEPT 5 Chapter 10 - Advanced Concepts 87 Chapter 2 - DATABASE PRIMER 9 Chapter 3 - GETTING STARTED 17 Chapter 4 - SECURITY ACCESS 31 Chapter 5 - OVERVIEW OF DATABASES AND FILES 37 Chapter 6 - CONFIGURATION DATABASE 43 Chapter 7 - LINKAGE DATABASE 59 Chapter 8 - DEFAULT USER PROFILE 73 Chapter 9 - ON-LINE INTERFACE 75 CHOICE DATABASES 63 COLOR 91 Color Code chart 91 command line parameters 24 command prompt replace display 38 communication serial ports 7 COMPORT 45 COMPORT OVERRIDE 47 22, 45, COMPOSER 6 COMPOSER Screen 20 Compression mode 51 Configuration Database 21, 43 Configuration Database Filename 38 cycle a caller 29 D Database Directory 20 Database Filename 20 Database Primer 9 61 DATE DBFNAME 43 DEFAULT 67, 69 DEFAULT LINK TYPES 67 default node configuration 21 Default Profile Display 49 103 Default Profile Display file 56 Default User Profile 73 Default User Profile Database 38 Default User Profile Field Display 40 Default User Profile System 49 DESCRIPT 44 DETECT MODE 52 DIGIBOARD 47 Digiboards 7 33 DigiZ Directory 20 DISPFILE 56 Display file for field 38 DISPLAY.XXX 39 Displays 38 DOOR 7, 27 DOOR COMPATIBILITY 27 DOOR FILENAME 27 DOOR.BAT 24 DOOR.SYS 46 27, DOOR.SYS PATH 22 DOORSYSPATH 46 DOORWAY 4 DORINFOx.DEF 27 DSZ 33 E 31 Edit Edit [#] 79 Edit Record Logic Flow and Rules 93 EDITMODE 53 ENDADD.XXX 38 ENDEDIT.XXX 38 ENDUSER.XXX 39 ENDUSER1.XXX 39 Error log filename 51 ERROR.LOG 39 ERRORLOG 51 F F10 29 104 F3 29 F4 29 29 F7 F8 29 29 F9 Fast or Slow Searches 82 Field Edit Display File 40 Field level security 34 FIELD PROCESSING LOGIC 95 FIELDNAME 60 Figure 10-1 87 Figure 2-1 10 Figure 2-2 15 Figure 3-1 20 Figure 7-1 76, 59, 78, 77, 84, 83, 82, 87 Figure 9-1 76 Figure 9-2 78, 77, 83, 82, 87 84, Figure 9-3 78, 77, 83, 82, 87 84, Figure 9-4 78 Figure 9-5 83, 82, 87 84, Figure 9-6 83, 82, 87 Figure 9-7 84 83, Figure 9-8 84 file attachments 19, 33 File Transfer System 33 Filename 20 92 FMEMO FMEMOI 92 FORCE 62 FORCE ANSI 52 FORCE RIP 52 FORM.BBS 87 FORM.XXX 38 FORMFILE 56 FOSSIL 47 Full Access 32 G 27 GAP GENERIC 27 GENERIC.SYS 27 105 Getting Started 17 Go or Table Search 83 Go Search 84 GRAPHICS 52 H HARDWARE 17 HELP.XXX 39 HELPFILE 56 HELPMEMO.XXX 39 I IBM EXTENDED CHARACTERS 52 INSTALL.COM 19 Installation 19 Introduction 1 J 62 JOB Job number 50 JOBNUMFILE 50 L LINK CONFIGURATION 21 Link type 60 Linkage Database 59 Linkage database 76 59, Linkage database filename 38 LINKAGE DATABASE SYSTEM 50 LMEMO 92 LMEMOI 92 Load MBACCESS 28 LOADMENU 44 LOCALBEEP 45 LOCKRETRYS 57 LZH 51 M MAIN database filename 38 MAIN MENU 86 106 Main menu display 49 Main menu display file 38 MAINMENU.XXX 38 Manual Layout 2 MBACCESS 9 6, MBACCESS - THE DOOR 27 MBACCESS DOOR Interface 28 MBACCESS MAIN MENU 86 MBACCESS WELCOME MENU 86 MBMANAGE 25 6, MBPRO.DBF Record Layout 10, 59 MBPRO.EXE 19 memo link types 92 MEMORY 17 MENUFILE 49 MINIMUM BASE MEMORY 18 ModemBase Pro Concept See also 5. Composer ModemBase Pro Manage 25 multi-node 33 Multi-node systems 24 multi-user 19 N 45 NAME No Access 32 NODE CONFIGURATION 21 nodes 4 Normal Field Help Display File 40 NOUSETIME 46 O OPERATIONAL CATEGORIES 31 Operational Requirements 17 OPTIONAL 94 68, ORDER.DBF Record Layout 15, 20 Overview of Databases and Files 37 Owner Access 32 OWNFIELD 44 107 P PCBoard(12-14.x) 27 PCBOARD.SYS 27 PORTAL 27 POSTPATH 56 PRIMARYIDX 57 Print Processing 93 50, PROCESS 50 PROCESSOUT 50 PROCESSRPT 51 PROMPT MODE 52 PROMPT.XXX 38 PROMPTFILE 56 Prompts file 38 PROMPTS.XXX 38 protocol 33 Q Quick BBS 27 Quick Start Installation 19 R 27 RA RBBS-PC 27 RECORD LAYOUT 10, 15 Record level security 34 RECORD LOGIC FLOW 98 Record view form file. 38 Record View/Edit Mode 78 Remote Access 27 Repeat options check 94 REPEAT TYPE 50 report 51 reports 19 RIPSCRIP file 41 S s[O]rt Browse Mode dynamic display 77, 78 s[O]rt selection list 78 77, 69, SAVED 94 108 search mode 84 search table 84 search tables 19 SEARCH.BBS 82 SEARCH.XXX 39 Searching with a keyword 82 Searchlight 27 Section II 25 Security Access 31 Security Access Tech Tips 36 Security Check 93 Security Modes of Access 32 SETUP.DOC 25 SHOWDELETE 56 61 SID SMENUFILE 49 SpitFire(3.x) 27 STARTADD.XXX 38 status display 28 SYSLEVEL 55 Sysop level 36 Sysop security level 55 T 65 TABLE Table Search 83 TABLE.BBS 83 TABLE.XXX 39 Technical Support 26 TEXT MODE 52 Text Report 33 TheDraw 42 TIME 61 TITLEOK 55 toolkit 4 transfer 31 Transfer mode security access 52 Transfer Security Mode 34 Transfer System 87 TWIRLSTRNG 57 TYPE 60 109 U UPLOAD 47 USER PROFILE. See DEFAULT USER PROFILE User Profile 14 V 31 View VIEW SECURITY MODE 34 VIEWMODE 54 VROOMM 17 W WCNODEID 24 WELCFILE 49 Welcome file 38 WELCOME MENU 86 WELCOME.XXX 38 What ModemBase Pro is Not. 3 Wildcat (2.x) 27 Wildcat (3.x-4.x) 27 WORKPATH 48 27 WWIV WYSIWYG 3 X Xfer 31 Xfer Security Access Modes 32 XFER SECURITY MODE 34 XFERKIT.ZIP 33 XFERMODE 52 Z ZIP 51 110